Pricing
Self-serve from the first call. Start free with no card, and move up only when your own usage says so — every plan below is bought in the dashboard, never through a sales call.
No fire, no charge
A watch bills when a change is delivered to you and your endpoint accepts it. A delivery that fails, or that repeats one you already received, is never charged for — metering runs after the acknowledgement, exactly once.
Plans
Free
$0/month
- Calls / rolling 24h
- 100
- Watches
- 3
- Delivered changes
- 50 included
- Row credits
- 0 included
- Spend cap
- 10,000 units · up to $1,000
Both free allowances are counted, not granted once: watches count while they are live, so cancelling one frees the slot again, and delivered changes count against the billing month and refill when it turns. Changes past that month's allowance are not delivered and are not sent afterwards — the feed is forward-only, never a backlog — and your console says when one was stopped.
Start free — no card →Trial
Granted at signup, not bought — 14 days, no card. It is a grant rather than a plan, so it carries no monthly price.
- Calls / rolling 24h
- 10,000
- Spend cap
- 10,000 units · up to $1,000
Starter
$49/month
- Calls / rolling 24h
- 50,000
- Watches
- 5
- Delivered changes
- 250 included
- Row credits
- 1,000 included
- Spend cap
- 25,000 units · up to $2,500
Growth
$199/month
- Calls / rolling 24h
- 200,000
- Watches
- 25
- Delivered changes
- 1,500 included
- Row credits
- 5,000 included
- Spend cap
- 100,000 units · up to $10,000
Enterprise
An annual commit with a shared usage pool, arranged once your account's own usage warrants it. There is no form here and no call to book: start on a self-serve tier and the enterprise bridge opens from inside the account.
Beyond what a plan includes, usage is metered at $0.10 per sourced company row. A delivered change is charged against that same unit. The billing system's own price list is public at /.well-known/pricing.json, and that is what your invoice follows.
Spend caps
Every self-serve plan ships with a hard cap already set, so metered usage cannot run away while you are asleep. The soft cap warns; the hard cap stops.
| Plan | Warns at | Stops at | Most it can cost |
|---|---|---|---|
| Free | 8,000 | 10,000 | $1,000 |
| Trial | 8,000 | 10,000 | $1,000 |
| Starter | 20,000 | 25,000 | $2,500 |
| Growth | 80,000 | 100,000 | $10,000 |
| Enterprise | — | — | no cap |
Caps are counted in metered units. The money column is that cap at the metered rate above, shown so the ceiling is legible.
Rate limits
Each API key has one request budget per fixed 60-second window. The window opens on the key's first request and resets 60 seconds later; it does not slide. REST calls and MCP tool calls made with the same key draw on the same budget, and a request that answers 404 counts like any other.
- Free: 20 requests per 60 seconds
- Trial: 100 requests per 60 seconds
- Starter: 500 requests per 60 seconds
- Growth: 2,000 requests per 60 seconds
Every response from a rate-limited route, refused or not, carries three headers: RateLimit-Limit (the budget for the window), RateLimit-Remaining (requests left in it) and RateLimit-Reset (seconds until it resets).
Past the budget the API answers 429 with a Retry-After header — whole seconds, the same number as RateLimit-Reset — and the body {"detail": {"reason": "rate_limited", "endpoint": "<path>"}}. Wait Retry-After seconds, then send the request again.
A 429 whose reason is key_throttled is a different refusal: the key is held by an abuse throttle rather than by the window, and it sends no Retry-After because there is no scheduled end to wait for.
rate_limited is also the name of a watch delivery status, and it means something else there: the watch fired more often than its own max_fires_per_hour and the extra deliveries were dropped. That is a setting on the watch, not your request rate, and it never arrives as an HTTP 429.