> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vine.getcourtyard.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Introducing Vine: know what any business runs, and where a customer can act
> The first endpoint of the API for the long tail of agentic commerce. Live today.
**TL;DR**: Give Vine a business's URL and it tells you the customer-facing software that business actually transacts through (OpenTable, Mindbody, Toast, Calendly, SevenRooms), plus the exact URL where a customer, or an agent acting for one, can book, order, or reserve. It's a live scan per request, not a lookup against a stale fingerprint database. Try it with no signup at [vine.getcourtyard.ai/try](https://vine.getcourtyard.ai/try).
Agentic commerce works beautifully, for about twenty businesses. The ones with public APIs, aggregator coverage, and well-documented endpoints show up in every demo. The other few million don't.
For the long tail, the very first question an agent has to answer has no clean API behind it: **what does this business actually run, and where does a customer act on it?** The answer is buried behind a themed website and a handful of third-party widgets. A dentist runs Mindbody at a specific scheduling URL. A boutique checks out through a specific storefront. A restaurant reserves through OpenTable at one deep link and orders through Toast at another. There was no good way to get that answer at scale, live, per URL.
So we built one.
## What Vine /detect does
Vine answers one question: given a business's URL, what customer-facing software does it run, and what's the exact URL where a customer can act on it?
You POST a URL. Vine renders the site, follows its calls-to-action the way a customer would, and resolves the real provider. You get back the software the business uses and a `detectionId`. Then you read the detection for the payoff: per provider, what a customer can do there (`book`, `reserve`, `order`, `schedule`, `pay`) and the resolved `actionUrl` where they do it.
This is a live scan, not a cached fingerprint. We look at the site as it exists right now, follow the buttons, and report what we find.
## How it works
Two calls. Detect once, read many.
**1. Detect.** Send the business URL. The call blocks while Vine scans the site live, typically a minute or two for a fresh URL, about a second for one detected recently.
```bash theme={"theme":{"light":"github-light","dark":"vitesse-dark"}}
curl -X POST https://vine.getcourtyard.ai/api/v1/detect \
-H "Authorization: Bearer $VINE_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "url": "https://some-restaurant.com" }'
```
```json theme={"theme":{"light":"github-light","dark":"vitesse-dark"}}
{
"detectionId": "det_01h...",
"url": "https://some-restaurant.com",
"providers": ["opentable"],
"durationMs": 68412,
"creditsUsed": 14
}
```
**2. Read the detection.** `GET /api/v1/detections/{id}` returns the agent-ready payload: the connections, each with an `actionType` and a resolved `actionUrl`: the place a customer, or an agent acting for one, actually engages the business.
```json theme={"theme":{"light":"github-light","dark":"vitesse-dark"}}
{
"connections": [
{
"provider": "opentable",
"actionType": "reserve",
"actionUrl": "https://www.opentable.com/r/...",
"status": "active"
}
]
}
```
That's the whole surface. No SDK to learn, no per-provider integration to maintain.
## Why fingerprinters can't do this
Wappalyzer and BuiltWith can tell you a site runs React and Google Analytics. They can't tell you a business runs Mindbody at *this exact scheduling URL*. That's a different question ("what tech is on this page" versus "what does a customer transact through, and where"), and it's answered from stale cached data with no CTA-following.
We wanted to know how large the gap actually is, so we measured it. We scored "which provider does this business run, and where does a customer act?" across 100 real business URLs spanning a wide range of categories:
| Tool | Correct provider + actionable URL |
| -------------------------- | --------------------------------- |
| **Vine** | **\~92%** |
| Traditional fingerprinters | \~31% |
The fingerprinters aren't bad tools. They're built for a different job. Naming the specific software and the URL a customer acts on, live, is the job Vine is built for.
## Built for agents
Most callers of this won't be humans; they'll be agents acting on someone's behalf. So alongside the API we shipped an [agent skill](https://vine.getcourtyard.ai/skill.md): a single self-contained markdown file an agent loads to work out *when* Vine is the right tool and *how* to drive it end to end.
It's a skill rather than just an OpenAPI spec because the awkward parts of using Vine aren't in the schema. A detect can come back `detection_incomplete` when a site is slow, and the right move is simply to retry. The `actionUrl` isn't always ready the instant detect returns (a background job resolves it), so you re-read the detection until it lands before acting. The skill writes that down, so an agent doesn't have to learn it by failing.
In practice: an agent told *"book me a pilates class at studio X"* loads the skill, runs detect, waits for the action URL, and opens the real booking page, instead of guessing `/book` or scraping a marketing page for a button.
## What you can build
Knowing what a business runs, and where a customer can act on it, is step one for a lot of workflows the long tail has been locked out of:
* **Agents that act on a business's behalf.** Detect the provider and go straight to the real URL, instead of scraping a homepage for a button.
* **Go-to-market.** Crawl a city's businesses, detect each, and get a list of who runs which provider, with the actionable link, ready for Clay or Attio.
* **Account research.** Enrich a target list with what a customer can actually do on each company's site, and through which provider. Software-in-use research, not firmographics.
Runnable examples for each: [vine.getcourtyard.ai/examples](https://vine.getcourtyard.ai/examples).
## Where this is going
Detect is the first endpoint of Vine, not the last. Next:
* **Extraction** of data from the providers we detect: schedules, menus, availability.
* **An MCP server and Claude connector**, so agents can call Vine natively.
* **Faster detects.** A live scan takes a minute or two today; we're targeting sub-30 seconds by the end of July.
## Get started
Vine is in public beta, labeled as such.
* **1,000 free credits on signup, no card**: [vine.getcourtyard.ai/keys](https://vine.getcourtyard.ai/keys).
* A live detect costs 12–26 credits (10 base + 2 per rendered page), roughly 40–80 free detects to start.
* Every response carries `vine-credits-used` and `vine-credits-remaining` headers.
* No paid tiers published yet. Burn through the free credits and email [contact@getcourtyard.ai](mailto:contact@getcourtyard.ai), and we'll top you up.
Try it right now, no key required: [vine.getcourtyard.ai/try](https://vine.getcourtyard.ai/try). Docs: [docs.vine.getcourtyard.ai](https://docs.vine.getcourtyard.ai).
***
*The head of the market got APIs years ago. The long tail gets one now.*