Documentation
Guide
Rate limits
120 requests per 60 seconds, per key. A sliding window, counted per key rather than per IP, so one tool misbehaving cannot spend another tool's budget — mint a key per integration and they never contend.
Over the limit you get a 429 with code rate_limited. No rate-limit headers are sent today — there is no X-RateLimit-Remaining or Retry-After to read, so treat the 429 itself as the signal and back off exponentially.
A capability is counted against a class, not a number of its own — the number belongs to the deployment and the class belongs to the operation. Each capability's page names its class.
| Class | What it covers | Relative budget |
|---|---|---|
read | Cheap reads — the shape most integrations spend their budget on. | The widest |
write | Anything that changes something. | Tighter than a read |
send | Anything that reaches a customer's phone or inbox. | The tightest, and for a different reason: what a runaway loop spends here is the shop's sending reputation, which no amount of database headroom buys back |
expensive | A model call, a document render, a fan-out scan. | Tightest by count |
Budgets are counted per shop and per credential, so two keys on one shop do not contend and one shop cannot spend another's. If you are syncing a lot, page with the cursor instead of re-fetching, and prefer webhooks over polling — a subscription costs you no requests at all.