Get started
Rate limits
Each API key has its own budget of 120 requests per 60 seconds, so one integration can never slow down another.
The budget refills continuously rather than resetting at a fixed boundary: a steady stream of requests is never cut off at the top of a minute. Every response reports where you stand:
| Header | Meaning |
|---|---|
X-RateLimit-Limit | Requests allowed per window. |
X-RateLimit-Remaining | Requests left right now. |
X-RateLimit-Reset | Unix time, in seconds, when your budget is full again. |
Retry-After | On a 429 only: seconds to wait before retrying. |
429 Too Many Requests
HTTP/1.1 429 Too Many Requests
Retry-After: 12
X-RateLimit-Limit: 120
X-RateLimit-Remaining: 0
{ "error": "rate_limited", "message": "Too many requests — limit is 120 per 60s. Retry in 12s.", "retryAfter": 12 }Staying under the limit
- Cache competition lists for a minute. Ticket counts change, but not faster than that matters on a listing.
- Use webhooks instead of polling for entries and draws.
- When polling a checkout session, poll every 2 to 3 seconds while the buyer is on the page, not faster.
- Planning a launch with heavy traffic? Ask us for a higher ceiling ahead of time.