Rate Limits

No rate limits are currently enforced on the read API or the WebSocket streaming API.

This will change: limits will be introduced before general availability and documented on this page, with standard 429 responses and Retry-After headers on the REST surface. Design your integration to:

• prefer WebSocket subscriptions over REST polling for anything you consume continuously (orderbook, trades, marks) — one subscription replaces arbitrary polling;
• batch historical reads with the documented limit/before cursors instead of many small requests;
• treat 429 as retryable with exponential backoff, even though it is not emitted today.

Transaction submission is governed by the sequencer's admission control rather than a fixed request quota.