Skip to main content
Every limit on this page exists in production today — there are no undocumented ones, and nothing here is aspirational.

Platform API

The Platform API (organization + user endpoints) currently has no fixed request-rate limit. Reasonable integration traffic — including bulk account provisioning — needs no throttling on your side.
Fair use applies: if a runaway integration ever degrades service we may contact you or introduce limits, announced in advance via the changelog. Design for it cheaply by respecting Idempotency-Key on writes and backing off on ENGINE_UNREACHABLE / IDEMPOTENCY_KEY_IN_PROGRESS — see Idempotency.

Trade API

The trade engine rate-limits per account, per action category using token buckets: each category has a burst capacity and a steady refill rate. Short bursts up to the capacity are fine; sustained throughput is the refill rate. Exceeding a bucket returns 429 with code RATE_LIMITED and full retry guidance in the body:
Handle it by sleeping rate_limit.retry_after seconds and retrying — that value is exact, not an estimate. The same rate_limit block also rides along on successful responses so you can pace proactively.
Limits are per account: a copy-trading leader fanning out to followers doesn’t consume the followers’ buckets — mirrored executions are internal and unmetered.

Webhooks & event stream quotas

Not request-rate limits, but the delivery-side quotas to size for (details in the webhooks guide):

Market Data API

No request-rate limits on the REST endpoints. Access is governed by licensing instead: a valid CME agreement plus active entitlements per user, and WebSocket entitlement refreshes are throttled to one per 2 seconds server-side.