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

BucketApplies toLimitKeyed by
Read requestsGET /api/v1/*120 requests / 60sper API key
Write requestsPOST /api/v1/*30 requests / 60sper API key
Failed authInvalid keys20 attempts / 60sper 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 a 429 response.

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
HTTP/1.1 429 Too Many Requests
X-RateLimit-Limit: 120
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1789000000
Retry-After: 42

{
  "error": {
    "code": "rate_limited",
    "message": "Too many requests. Retry after 42 seconds."
  }
}

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.