Per-tenant ceilings

• 60 requests / minute (1 rps sustained, 60-call burst tolerance)
• 2,400 requests / hour (40 rpm sustained over the hour)
• Counters are per-tenant — the key’s tenant ID is the bucket key
• Sliding window — no calendar-edge reset surprises

The 60 rpm + 2,400 rph asymmetry is intentional: short bursts (a checkout page rendering 30 cards) are absorbed by the minute window, but a sustained 60 rpm forever isn’t. The hour ceiling is the steady-state cap.

HTTP/1.1 429 Too Many Requests
Retry-After: 17
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1747700617
Content-Type: application/json

{
  "error": "rate_limited",
  "message": "Rate limit exceeded. Retry after 17 seconds.",
  "retryAfterSeconds": 17
}

Retry-After is the number of seconds until the oldest in-window request ages out. Standard HTTP semantics — most retry middleware respects it automatically (urllib, axios with retry-axios, etc.).

Default 60/2,400 covers checkout-page + occasional catalog mirror traffic. If you need real-time market-making volume or full-catalog indexing, email [email protected] with your expected sustained rpm + hour totals. Higher tiers are issued per-partner after a brief usage review.

• Every successful 2xx response — full charge.
• Every 4xx authentication failure — full charge (so brute-force enumeration costs the attacker).
• Every 5xx server error — refunded automatically (our fault, not yours).
• HEAD + OPTIONS — full charge (cheap on the server, but still a billable round-trip).

For polling integrations: respect Retry-Afteron the first 429, then jitter the next attempt. Don’t retry-tight- loop — the limiter sees your second attempt within the same window and re-429s. Sustained 429s on the same key trip an alerting threshold on our side; we’ll reach out before rate-zeroing the key.