Rate Limits
Three sliding-window limiters apply to API requests. The numbers below are the ones enforced in production; they are identical in test mode.
Per API key
100 req / min
Every /v1 endpoint. 429 with error.code rate_limit_exceeded; no Retry-After header, wait up to 60 s.
Per IP (platform)
300 req / min
All /api/* traffic, before authentication. 429 with a flat body { "error": "Too many requests. Please slow down." } and X-RateLimit-* + Retry-After headers.
Route-specific limits
| Route | Limit | Scope |
|---|---|---|
| POST /v1/billing/meter-events, POST /v1/billing/meter-event-adjustments | 60,000 / min | per key (replaces the 100/min bucket on these routes) |
| POST /v1/checkout/sessions | 20 / min | per key, in addition to the 100/min key limit |
| Public checkout, payment-link and invoice pages | 5 charge attempts / min, 10 tokenizations / min | per customer IP (protects your buyers, not API-key traffic) |
- Limits are per key: a second key for the same business has its own budget; processes sharing one key share it.
- Fail-open: if the limiter's store is unreachable the request is allowed through.
- There are no per-operation hourly quotas ("50 charges per hour" and similar figures shown on earlier versions of this page are not enforced).
- Monthly transaction caps come from your plan and answer
403 tier_limit_exceeded, not 429.