Rate limits
Requests are rate limited per API key over a rolling 60-second window. Every response carries headers telling you exactly where you stand.
Limits
| Bucket | Applies to | Limit | Keyed by |
|---|---|---|---|
| Read requests | GET /api/v1/* | 120 requests / 60s | per API key |
| Write requests | POST /api/v1/* | 30 requests / 60s | per API key |
| Failed auth | Invalid keys | 20 attempts / 60s | per IP address |
Rate limit headers
Every API response includes these headers so you can throttle proactively:
X-RateLimit-Limit— the maximum requests allowed in the current window.X-RateLimit-Remaining— requests left in the current window.X-RateLimit-Reset— unix seconds when the window resets.Retry-After— seconds to wait, sent only on a429response.
When you exceed a limit
Once a bucket is exhausted, further requests return 429 rate_limited until the window resets. Respect the Retry-After header and back off before retrying.
HTTP/1.1 429
Design for the limit
Cache reads you make repeatedly, and prefer polling an invoice every few seconds rather than in a tight loop. When webhooks ship, you'll be able to drop most polling entirely.A separate, stricter limit protects against credential stuffing: repeated requests with an invalid key are throttled per IP. See Authentication.