Meta description: Learn CoinGecko API rate limits, latency, batching and best practices to scale high-traffic crypto apps — plus hybrid architectures with Codex.

CoinGecko API Rate Limits, Latency & Throughput: Scaling for High‑Traffic Apps

If you’re building a trading interface, portfolio dashboard, or token‑aware product, you’ve probably started with CoinGecko. It’s ubiquitous, easy to use, and offers broad coverage.

But once traffic ramps up, CoinGecko API rate limits and CoinGecko API latency become critical design constraints. This guide summarizes what the official docs say about limits, caching, and delivery, and how to design around them.

We’ll also show how teams pair CoinGecko with on‑chain APIs like Codex to get trading‑grade performance without abandoning CoinGecko’s breadth.

All numeric claims about CoinGecko in this article are sourced directly from CoinGecko docs/support pages and verified as of 2026‑09‑14.

---

Benchmark methodology (how we think about performance)

Before diving into specific numbers and patterns, it’s important to clarify what’s measured and what’s vendor‑reported.

1. CoinGecko numbers

All CoinGecko metrics (rate limits, cache windows, WebSocket quotas, batch sizes) are taken from:

• CoinGecko Support — rate limits, caching, WebSocket status, 429 behavior, etc. (support.coingecko.com, verified 2026‑09‑14)
• CoinGecko Docs — endpoint references for simple/price, simple/token_price, on‑chain price, and WebSocket limits. (docs.coingecko.com, verified 2026‑09‑14)

We do not infer latency from these docs; they only describe quotas and cache windows.

2. Codex numbers

Codex metrics (throughput, WebSocket scale, latency claims) are taken from Codex’s own public materials:

• Codex pricing (requests/month, requests/second): codex.io/pricing, verified 2026‑09‑14
• Codex product page and docs (sub‑second freshness, WebSocket connections, retry/backoff guidance): codex.io/product and docs.codex.io, verified 2026‑09‑14

All Codex performance numbers should be treated as vendor claims unless you benchmark independently. Later in this guide we outline a simple test plan you can run yourself.

3. Latency testing approach (recommended)

Because CoinGecko doesn’t publish exact latency SLAs, you should benchmark from your stack. A typical methodology:

• Locations: run tests from at least 2 regions (e.g., US‑East, EU‑West) using the same code path as production.
• Endpoints: include both cached endpoints (/simple/price) and heavier ones (e.g., /coins/{id}, /onchain/simple/price).
• Concurrency: measure at several levels (1, 5, 20, 100 concurrent requests) to see fan‑out behavior.
• Cache priming: test both cold (first request) and warm (after a few calls) to understand cache impact.
• Time of day: run at different times to see peak vs off‑peak variance.
• Stats: log median (p50), p95, p99 latencies and error rates (especially 429s and 5xx).

You can replicate the same methodology for Codex or any other provider to build an apples‑to‑apples comparison.

---

CoinGecko API rate limits: what you can and can’t do

CoinGecko’s API is designed for broad market data access, not unbounded streaming. Most limits are expressed as requests per minute (rpm) per API key or per IP.

Public and keyless CoinGecko API rate limits

Per CoinGecko support, the public plan is limited to roughly 5–15 requests per minute (rpm) for most endpoints, depending on the endpoint and traffic profile (CoinGecko Support — Rate Limits, 2024‑04‑05, verified 2026‑09‑14).

• Public plan:
  • Scope: requests/minute per IP / keyless pool.
  • Typical range: ~5–15 rpm.
  • Use case: casual experimentation, non‑production scripts.

CoinGecko also offers a keyless public pool, where requests without an API key share a global rate limit:

• ~10–30 requests/minute for CoinGecko endpoints.
• ~10 requests/minute for GeckoTerminal endpoints.

Source: CoinGecko docs on the keyless public API (docs.coingecko.com — Keyless Public API, verified 2026‑09‑14).

Implication: Keyless and public tiers are not suitable for high‑traffic apps. You’ll hit 429s quickly.

Demo and paid plans: per‑key rate limits

CoinGecko’s documented rate limits for paid and demo plans, per API key, are:

• Demo plan:

  • 100 requests/minute per API key.
  • Source: CoinGecko docs on errors & rate limits (docs.coingecko.com — Errors and Rate Limits, verified 2026‑09‑14).

• Paid plans:

  • 500 or 1,000 requests/minute per API key depending on plan (e.g., Basic vs Analyst+).
  • Source: CoinGecko support on paid API limits (support.coingecko.com — Paid API Rate Limits, verified 2026‑09‑14).

• Enterprise:

  • Custom requests/minute per API key, configurable per key.
  • Source: CoinGecko support — custom rate limits by key for Enterprise clients (support.coingecko.com — Custom Rate Limits, verified 2026‑09‑14).

CoinGecko also notes that:

• 429 (Too Many Requests) indicates you hit your per‑minute rate limit.
• Failed requests still count against the limit.
• Recommended mitigation is to reduce request volume or upgrade plans.

Source: CoinGecko support on 429 errors (support.coingecko.com — 429 Errors, verified 2026‑09‑14) and errors & rate limits docs (docs.coingecko.com — Errors and Rate Limits, verified 2026‑09‑14).

CoinGecko API caching strategy and freshness windows

CoinGecko’s API is heavily cached. Their support docs explicitly state that most endpoints are cached and emphasize that polling faster than the cache window does not improve freshness.

Key cache windows (paid API) as of the latest docs:

• Most endpoints: cache around 1–5 minutes.
• simple/price endpoint:
  • About 30 seconds cache window on paid plans.
• simple/token_price endpoint:
  • About 20 seconds cache window on paid plans.
• coins/list endpoint:
  • About 5 minutes cache window.
• supported_currencies endpoint:
  • Around 60 seconds cache window.

Source: CoinGecko support on data refresh frequency (support.coingecko.com — Data Refresh Frequency, verified 2026‑09‑14).

CoinGecko’s guidance is clear: throttle rather than spam. Their docs say:

• Over‑polling wastes bandwidth and does not deliver fresher data when endpoints are cached.
• Use fields like include_last_updated_at=true and include_24hr_change=true on simple/price to detect whether a price has actually changed.

Source: CoinGecko API reference for simple/price (docs.coingecko.com — simple/price, verified 2026‑09‑14).

---

CoinGecko API batching requests: how far you can scale a single call

Because rate limits are strict, batching is the primary scaling tool recommended inside CoinGecko’s own docs.

Key batch caps as of the latest documentation:

• simple/price (market data):

  • Up to 515 coin IDs per request for paid API.
  • Source: CoinGecko docs for simple/price (docs.coingecko.com — simple/price, verified 2026‑09‑14).

• simple/token_price (token prices by contract address):

  • Up to 515 contract addresses per request on paid API.
  • Source: simple/token_price reference (docs.coingecko.com — simple/token_price, verified 2026‑09‑14).

• On‑chain simple price endpoints (per chain):

  • Up to 100 contract addresses per request on Analyst+.
  • Up to 30 contract addresses per request on Demo.
  • Source: on‑chain simple price docs (docs.coingecko.com — onchain/simple/price, verified 2026‑09‑14).

Design implication: For high‑volume watchlists (hundreds to low thousands of assets), you should:

• Partition portfolios into batches of ≤515 IDs for simple/price or simple/token_price.
• Align polling cadence with cache windows (e.g., 20–30 seconds) instead of per‑asset polling.
• Use local caching/memoization to further minimize external calls.

We’ll translate this into concrete patterns later in the guide.

---

CoinGecko API latency: what to expect and how to measure

CoinGecko does not publish official latency SLAs. However, based on its architecture (REST + caching), you can infer a few practical characteristics:

• Responses are cache‑governed. After the first request in a cache window, subsequent requests during that window should be served from cache, often faster.
• Latency depends on:
  • Endpoint complexity (simple/price vs full /coins/{id}).
  • Geographic distance between your server and CoinGecko’s infrastructure.
  • Network conditions and time of day.

To get concrete numbers, you should run your own benchmarks using the methodology described earlier.

In practice, many teams see p50 latencies in the low hundreds of milliseconds for simple endpoints and higher for complex ones, but this is environment‑specific and not guaranteed.

Because CoinGecko’s own docs don’t specify exact latency, treat any hard numbers as your environment’s measurements, not global truths.

---

CoinGecko WebSocket & Webhook support (beta)

CoinGecko has moved beyond pure polling by offering WebSocket and Webhook delivery — but with important caveats.

WebSocket status and limits

Per CoinGecko support, WebSocket is currently in beta and is excluded from any SLA as of the latest docs (support.coingecko.com — WebSocket/Webhook Support, verified 2026‑09‑14).

Detailed limits (per CoinGecko WebSocket docs):

• WebSocket product is metered by credits.
• Limits by plan:
  • Basic: 5 concurrent connections.
  • Analyst+: 10 concurrent connections.
  • (Other plans may vary; check latest docs.)
• Subscriptions: up to 100 subscriptions per channel per socket.
• Credits: roughly 0.1 credit per response.
• Ping cadence: server sends a ping every 10 seconds to keep the connection alive.

Source: CoinGecko WebSocket docs (docs.coingecko.com — WebSocket, verified 2026‑09‑14).

Implications:

• WebSocket helps reduce REST calls for live price streaming, but:
  • It is beta and not covered by SLA.
  • It is metered, so large fan‑out patterns can become expensive.
  • Connection limits force careful multiplexing (e.g., 100+ symbols per connection).

Webhooks

CoinGecko also mentions Webhooks as an alternative delivery method for some products, but details and coverage are still evolving. As of the latest support article, Webhooks are available on paid plans for certain use cases (support.coingecko.com — WebSocket/Webhook Support, verified 2026‑09‑14).

Treat Webhooks as complementary to REST for event‑driven flows rather than a full replacement for continuous streaming.

---

CoinGecko API rate limiting best practices

CoinGecko’s own docs encourage infra discipline. They explicitly say to avoid over‑polling and to handle rate limits gracefully.

Here are practical best practices for high‑traffic apps.

1. Centralize calls through your backend

CoinGecko recommends proxying calls through a backend rather than directly from the browser because of CORS and security considerations (docs.coingecko.com — Errors and Rate Limits, verified 2026‑09‑14).

• Do:

  • Have a single server‑side service call CoinGecko.
  • Fan out results to clients via your own WebSockets/HTTP.

• Don’t:

  • Let each client call CoinGecko directly — you’ll multiply traffic and hit rate limits faster.

2. Use batching aggressively

Batching is your primary tool to stay under rpm limits:

• Group watchlists into ≤515 ID batches for simple/price.
• Group contract addresses into ≤515 per request for simple/token_price.
• For on‑chain price endpoints, respect caps of 30 or 100 addresses per request depending on your plan.

3. Align polling cadence with cache windows

Remember the cache windows:

• simple/price: ~30s.
• simple/token_price: ~20s.
• Most endpoints: 1–5 minutes.

Polling every second defeats the purpose and does not increase freshness.

• Set polling intervals to >= cache window where possible.
• Use include_last_updated_at to detect stale vs fresh data.

4. Handle 429s with backoff, not retry storms

CoinGecko treats 429 as a scaling signal; they explicitly recommend reducing calls or upgrading (support.coingecko.com — 429 Errors, verified 2026‑09‑14).

Your client should:

• Respect any Retry-After or retryAfterSeconds header if present.
• Implement exponential backoff.
• Log and alert on sustained 429s — they indicate mis‑sized polling or a need for a higher plan.

5. Cache on your side too

Even with CoinGecko caching, you should maintain your own:

• In‑memory cache for hot symbols.
• Short‑lived application cache (e.g., Redis) keyed by endpoint + params.
• HTTP cache (etag/last‑modified if supported) where applicable.

This lets you serve most requests from your own infra while respecting per‑minute limits.

---

Hybrid architecture: pairing CoinGecko with an on‑chain API like Codex

For trading‑grade UX, teams often discover that CoinGecko alone is not enough. It’s optimized for coverage and cached delivery, not tick‑level performance.

A common architecture is a hybrid stack:

• CoinGecko for:

  • Broad market coverage and reference data.
  • Long‑tail token discovery and global rankings.
  • Less time‑sensitive endpoints where 20–60s cache windows are acceptable.

• On‑chain data API (e.g., Codex) for:

  • Live token and pool prices (sub‑second freshness, vendor‑claimed).
  • Trading‑grade OHLC/candles and volume.
  • Real‑time wallet balances and holder data.
  • Prediction market events and trades.

Codex overview (vendor claims)

Codex.io describes itself as a high‑performance on‑chain data API focusing on token and prediction market data.

Per Codex’s public site and docs (vendor‑reported, verified 2026‑09‑14):

• Coverage:
  • 80+ networks.
  • 70M+ tokens.
  • 700M+ wallets.
  • 16 launchpads.
• Data types:
  • Real‑time and historical token prices (USD + native).
  • Trading‑ready chart data (OHLC, candles, volume).
  • Aggregates: liquidity, volume, unique wallets, TVL‑like stats.
  • Holders and balances across chains.
  • Scam filtering and token metadata.
  • Prediction markets (Polymarket, Kalshi and others) with events, markets, trades, trader analytics (in beta).
• Performance:
  • Marketing claims sub‑second data freshness and low‑latency query paths (<1s, some <500ms).
  • Growth plan: 1M requests/month, 300 requests/second, WebSockets and webhooks included.

Sources: codex.io/product, codex.io/pricing, docs.codex.io.

Codex also states that it powers apps including Coinbase, TradingView, Uniswap, Magic Eden, Rainbow, MoonPay, Farcaster, and pump.fun. Treat these as vendor‑reported customer examples; verify individually if you require independent confirmation (codex.io, verified 2026‑09‑14).

Example: using Codex for live DEX prices, CoinGecko for market cap

A practical design:

1. Token discovery (CoinGecko):

   • Use /coins/list to find token IDs.
   • Use /coins/{id} for metadata and market cap.

2. Live on‑chain prices (Codex):

   • Use Codex’s token price query for a given chain and contract.

   Example GraphQL‑style query (from Codex docs, simplified):

   query TokenPrices($inputs: [TokenPriceInput!]!) {
     tokenPrices(inputs: $inputs) {
       tokenAddress
       chainId
       priceUsd
       priceNative
       liquidityUsd
       volume24hUsd
       updatedAt
     }
   }
   

3. Charting (Codex):

   • Use Codex OHLC/candle endpoints for high‑resolution charts.

   Example:

   query Candles($input: CandlesInput!) {
     candles(input: $input) {
       open
       high
       low
       close
       volume
       intervalStart
     }
   }
   

4. Prediction markets (Codex):

   • Use filterPredictionEvents or filterPredictionMarkets for Polymarket/Kalshi feeds.

   Example:

   query PredictionEvents($filter: PredictionEventsFilter!) {
     filterPredictionEvents(filter: $filter) {
       id
       title
       platform
       status
       markets {
         id
         yesPrice
         noPrice
         volume24hUsd
       }
     }
   }
   

5. Fallback / complement (CoinGecko):

   • For assets not yet covered by Codex, fall back to CoinGecko simple/token_price.

Rate‑limit strategy in hybrid stacks

• Treat CoinGecko as secondary for live UX; rely on Codex for hot paths.
• Use CoinGecko mainly for:
  • Daily/6‑hour sync jobs.
  • Refreshing symbols, logos, descriptions.
  • Sanity‑check prices against on‑chain.

This keeps CoinGecko traffic low and predictable while giving users sub‑second live updates via Codex (per vendor claim).

---

Best crypto data APIs for high traffic trading apps (2024)

To help with vendor selection, here’s a high‑level comparison of major crypto data APIs oriented around rate limits (requests/minute), high‑level latency characteristics, and recommended use cases.

Rate limits below are derived from each vendor’s public pricing/docs as of 2026‑09‑14. Latency is described qualitatively unless an SLA is explicitly stated.

Summary table (conceptual)

• CoinGecko

  • Public: ~5–15 requests/min per IP.
  • Demo: 100 requests/min per key.
  • Paid: 500–1,000 requests/min per key; Enterprise custom.
  • Latency: cache‑governed, no SLA.
  • Best for: broad market data, long‑tail coverage, non‑HFT trading UIs.

  Sources: CoinGecko public plan, paid limits, demo/errors docs, verified 2026‑09‑14.

• CoinMarketCap

  • Builder: 50 requests/minute.
  • Startup: 300 requests/minute.
  • Growth: 600 requests/minute.
  • Pro: 750+ requests/minute.
  • Enterprise: 1,600+ requests/minute, SLA 99.95% uptime.
  • Best for: centralized exchange (CEX) listings, reference prices, enterprise SLAs.

  Source: CoinMarketCap API pricing page (coinmarketcap.com/api/pricing, verified 2026‑09‑14).

• Codex (on‑chain focus, vendor claims)

  • Growth plan: 1M requests/month, up to 300 requests/second (~18,000 rpm) per pricing page.
  • WebSockets & webhooks included on paid plans.
  • Latency: vendor claims sub‑second data freshness.
  • Best for: on‑chain token prices, DEX markets, wallets, prediction markets.

  Source: codex.io/pricing, codex.io/product, verified 2026‑09‑14.

• Other on‑chain providers (e.g., Alchemy, QuickNode, Infura)

  • Focus: raw node/RPC access rather than enriched token markets.
  • Limits: often expressed as requests/day or compute units; vary widely.
  • Best for: low‑level contract reads, event logs, custom indexing.

• DEX‑specific APIs or explorers (e.g., GeckoTerminal, DEX‑oriented aggregators)

  • Limits: often 10–60 requests/minute on public/free tiers.
  • Best for: specific DEX analytics; less ideal as a unified data layer.

For high‑traffic trading apps, the pattern that emerges:

• Use CoinGecko or CoinMarketCap for broad, cached market data.
• Use Codex or another on‑chain data specialist for low‑latency, trading‑grade feeds.
• Avoid overloading basic REST APIs by introducing WebSockets and internal caches.

---

Practical design patterns: how to scale CoinGecko in real apps

Let’s turn these constraints into concrete patterns you can drop into your architecture.

Pattern 1: Central price cache service

Goal: Serve all client price requests from your infra while calling CoinGecko sparingly.

How it works:

1. Implement a price-cache-service (Python, Node, Go, etc.).
2. Expose endpoints like /prices?symbols=BTC,ETH,SOL to your frontend.
3. On the backend:
   • Batch symbols into ≤515 IDs.
   • Call CoinGecko’s simple/price every 20–30s.
   • Store results in Redis or in‑memory cache with timestamps.
4. Serve every client request from your cache; refresh asynchronously.

Benefits:

• Stays under 500–1,000 rpm even for millions of client hits.
• Keeps CoinGecko traffic predictable and low.

Pattern 2: Hybrid Codex + CoinGecko price layer

Goal: Use CoinGecko for coverage and Codex for real‑time trading UX.

How it works:

1. Mapping layer: Maintain a mapping of symbol -> (geckoId, chainId, contractAddress).
2. Discovery:
   • Use CoinGecko’s /coins/list and /coins/{id} for new assets.
3. Live prices:
   • Use Codex tokenPrices for real‑time DEX/chain prices.
4. Fallback:
   • If Codex doesn’t support a token yet, call CoinGecko simple/token_price.
5. Reconciliation job:
   • Periodically compare CoinGecko and Codex prices for anomalies.

Benefits:

• Trading interface remains reactive and low‑latency.
• You retain CoinGecko’s breadth and familiar endpoints.

Pattern 3: WebSocket fan‑out over your own infra

Goal: Avoid hitting CoinGecko’s beta WebSocket limits while still giving users live updates.

How it works:

1. Use Codex WebSockets (vendor supports 300+ concurrent connections on Growth plan, per docs) or your own polling/streaming layer.
2. Have a small number of upstream connections aggregate data.
3. Broadcast updates via your own WebSocket cluster (e.g., using Redis pub/sub or Kafka) to end‑users.

Benefits:

• Limits vendor WebSocket consumption.
• Gives you full control over reconnect, backoff, and multiplexing.

Pattern 4: Prediction market dashboards

Goal: Build Polymarket/Kalshi dashboards that feel like trading terminals.

How it works:

1. Use Codex filterPredictionEvents and filterPredictionMarkets for:
   • Live event lists and status.
   • Market odds, spreads, and volumes.
   • Trader‑level analytics.
2. Use CoinGecko only where CEX/spot prices are needed for reference.

Benefits:

• Offloads prediction‑market‑specific indexing to Codex.
• Keeps CoinGecko usage limited to classic price feeds.

---

FAQ: CoinGecko API performance and hybrid architectures

1. How often does CoinGecko update prices?

Per CoinGecko support, most endpoints are cached for about 1–5 minutes, with simple/price around 30 seconds and simple/token_price around 20 seconds on paid plans (support.coingecko.com — Data Refresh Frequency, verified 2026‑09‑14).

Polling more frequently than those cache windows typically does not increase freshness.

2. What are CoinGecko’s API rate limits for production use?

For paid plans, CoinGecko documents 500 or 1,000 requests per minute per API key, depending on the plan, and custom limits for Enterprise (support.coingecko.com — Paid API Rate Limits, verified 2026‑09‑14).

For high‑traffic apps, you should rely on batching and internal caching so that external rpm stays within these bounds.

3. Does CoinGecko support WebSocket or Webhook streaming?

Yes, but with caveats. CoinGecko’s WebSocket product is in beta and excluded from SLA as of the latest docs (support.coingecko.com — WebSocket/Webhook Support, verified 2026‑09‑14).

WebSocket limits include:

• Basic: 5 concurrent connections.
• Analyst+: 10 concurrent connections.
• Up to 100 subscriptions/channel/socket.
• Ping every 10 seconds.

Source: docs.coingecko.com — WebSocket, verified 2026‑09‑14.

4. How does Codex differ from CoinGecko for trading apps?

CoinGecko is a market data aggregator with strong coverage and cached endpoints.

Codex (per vendor claims) is an on‑chain data infrastructure optimized for:

• Sub‑second token and DEX prices.
• Trading‑grade OHLC/candles and aggregates.
• Wallet balances and holders.
• Prediction market data.

Codex exposes everything via a unified GraphQL‑style API and emphasizes high throughput (e.g., up to 300 requests/second on some plans, per codex.io/pricing, verified 2026‑09‑14). You should benchmark both in your environment.

5. What’s the best architecture for a high‑traffic crypto trading app?

For most product teams, the most robust pattern is:

• Use CoinGecko (or CoinMarketCap) for broad market data, rankings, and long‑tail coverage, respecting rate limits and cache windows.
• Use Codex or another on‑chain API for low‑latency pricing, charting, wallets, and prediction markets.
• Introduce a central caching layer in your backend that batches requests and exposes a stable internal API to your frontends.

This hybrid approach gives you both breadth and speed without building years worth of indexing and ETL infrastructure yourself.

---

If you’re evaluating a hybrid architecture or migrating from CoinGecko‑only to a combined CoinGecko + Codex stack, start by identifying your latency‑critical paths (trading views, real‑time balances) and move those to an on‑chain source first while keeping CoinGecko for everything else.