Skip to main content

​
Rate Limits

Each plan has a per-second rate limit on API requests: Requests that exceed your rate limit will be rejected. If you consistently hit your rate limit, consider optimizing your usage or upgrading your plan.

​
How Requests Are Counted

Every interaction with the Codex API counts against your plan’s monthly request limit. Usage is counted per query response, not per HTTP request. Here’s how each type of interaction is measured: A few details to keep in mind:
  • Aliased queries each count separately. If you combine multiple queries in one request using aliases, each query response is counted on its own, so filterTokens plus getDetailedTokenStats in one request counts as two.
  • Open subscriptions are free when idle. Subscriptions count one request per delivered message. An open subscription with no messages flowing does not consume usage.
  • Webhooks count only on delivery. A webhook counts only when a message is delivered, meaning when your condition is met. Codex’s internal evaluation of events against your conditions is not counted.
Subscriptions can generate a high volume of requests depending on what you’re subscribed to. For example, subscribing to trade events on a high-volume token could produce thousands of messages per hour — each one counts as a request.

​
Overages

Overages are charged at the same per-million rate as your subscribed plan. For example, if you exceed your 1M Growth plan limit by 500K requests, you’ll be charged for an additional 1M requests at the same per-million rate. For high-volume usage (10M+ requests/month), contact us on Discord or via email for custom plan pricing with volume discounts.

​
WebSocket Connection Limits

WebSocket connections are the transport layer for subscriptions. Each connection can carry multiple subscriptions. Connection limits are per API key. Each connection can handle multiple subscriptions, so the connection limit is rarely a bottleneck.

​
Capacity Per Connection

There is no hard limit on subscriptions per connection. What matters in practice is the total number of tokens being watched on that connection and how active those tokens are — not the count of subscribe messages. As a starting point, plan for up to ~100 tokens watched per connection. Spread tokens across connections rather than packing them onto one — if a single connection ends up carrying all your high-volume tokens (SOL, top trending tokens, busy pairs), it’ll drop messages while your other connections sit idle. If you see drops, reduce the per-connection token count and add more connections. The actual ceiling depends on:
  • Throughput — subscribing to onTokenEventsCreated for SOL generates far more messages than a low-volume token
  • Network capacity — your internet connection and proximity to Western US affect throughput
  • Subscription type — low-throughput streams like metadata updates can be packed considerably denser, while high-volume streams (launchpad events, busy chains) warrant dedicated connections
Note: onPricesUpdated accepts up to 25 tokens per input array — that’s a hard cap on a single subscription request, not a recommended connection density. You can run multiple onPricesUpdated subscriptions on the same connection, just count their combined tokens against the per-connection budget.

​
Reducing Usage

For best practices on batching requests, caching, managing subscription lifecycle, and other ways to minimize your request count, see Optimization.
Deactivating an API key does not automatically close active WebSocket connections. You must explicitly close your connections or they will continue to consume requests until they disconnect.