Rate limits
Throughput is counted per key, over a one-minute window. The ceiling depends on the account plan: 60 requests per minute on Free, 600 on Pro.
Ceilings
| Plan | Requests per minute |
|---|---|
| Free | 60 |
| Pro | 600 |
Headers
Every response carries X-RateLimit-Limit and X-RateLimit-Remaining. A 429 also carries Retry-After, in seconds. Read those headers rather than counting your calls: the ceiling can change with the plan, at runtime.
HTTP/1.1 429 Too Many Requests
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 0
Retry-After: 37
{ "error": { "code": "rate_limited",
"message": "Rate limit of 60 requests per minute exceeded." } }Per key, not per account
Two integrations on the same account therefore do not starve each other, and you can tell which one is consuming. It is also what makes revoking a runaway key immediately useful to the rest of the account.
On a 429
Wait the number of seconds given by Retry-After, then retry. The window is fixed: past that delay the counter is back to zero.
Paginate with a high limit rather than many small pages: a hundred items cost one request, not a hundred. For a sync, call /v1/commissions with from set to your last run instead of re-reading everything.