Coingecko API credits versus per-minute limits

Monthly allowance and burst capacity

Monthly credits govern total successful REST usage, while the minute limit caps request traffic during short periods of concentrated activity. A remaining monthly balance describes unused allowance over that longer period. It doesn’t reserve capacity for the next request or establish that the account can accept another burst.

A plan’s call allowance, request rate, and endpoint access are separate specifications. A larger monthly allowance won’t necessarily address short bursts. A higher rate won’t make a sustained polling schedule affordable in credits. The relevant figures come from the plan and the account’s configured limits. These settings can change with a subscription or an applicable account adjustment, so old hard-coded numbers can misrepresent available capacity.

Compatible keys and endpoint access

Demo and paid Pro API requests use different authentication headers and API environments, and the key must match the selected environment. The Demo header is x-cg-demo-api-key; the paid API header is x-cg-pro-api-key. The Pro API interface covers paid subscriptions, including tiers that have other names. Endpoint eligibility remains a separate requirement, even after authentication succeeds. Error code 10005 identifies an endpoint that the plan doesn’t permit. Increasing retries or having spare credits doesn’t grant that permission. Authentication compatibility and endpoint access therefore need their own configuration checks before automatic traffic resumes.

Failed calls and retry traffic

Under Demo and paid REST plans, each HTTP 200 request deducts one monthly credit, regardless of how many supported results it contains. Responses in the HTTP 4xx and 5xx ranges don’t deduct monthly credits. Failed attempts can therefore increase request traffic without producing matching deductions in the account’s credit balance.

For keyed REST access, all requests count toward the per-minute rate limit, including requests that return HTTP 4xx and 5xx errors. A malformed parameter or missing permission needs a configuration correction. Sending the request again unchanged uses more rate-limit capacity without addressing its cause. Automatic retries also belong in the application’s request count.

Exponential backoff increases the wait between retries. A capped retry policy prevents endless attempts, while a shared queue can pace new work alongside delayed retries.

Why can a 429 appear with credits remaining?

A 429 response can identify a minute limit, a monthly account limit, or a configured key-level credit limit. Its error body matters because the same HTTP code covers different restrictions. A positive account balance doesn’t rule out a key’s own hard monthly cap. Where Enterprise key-level controls are enabled, that cap can stop one key while other active keys retain access.

Requests without an API key use IP-based rate limiting, which users sharing an IP also share. A local request log can’t establish the total traffic from a shared IP. That restriction needs separate treatment from the monthly credit balance of an authenticated account.

View full-size image

Batch requests and result coverage

Bulk queries reduce call consumption by returning supported data for several assets within the same successful REST request. The /simple/price endpoint accepts multiple coin IDs and target currencies. The /coins/markets endpoint returns market data for a list of coins, including prices, market capitalization, and trading volume. These functions support different response needs, so the smallest useful request depends on the required fields.

Batching must respect each endpoint’s accepted parameters and request-size limits. Pagination creates separate requests for additional result pages, even when those pages belong to one data pull. Optional response fields can reduce separate lookups when the endpoint supports them. An HTTP 200 status doesn’t establish that every requested asset appears or every value is available. Response coverage needs attention alongside call counting, particularly when a broad query spans several pages.

Polling frequency and data freshness

Data freshness follows the selected endpoint’s update behavior, so more successful polls don’t necessarily produce newer crypto prices or market data. The price endpoint can include its last-update timestamp through include_last_updated_at. That timestamp describes the price update, separately from the time the application received its response. Local caching can reuse a response without sending another upstream request for each display refresh. Cache entries need to preserve the selected assets, currencies, and response options. A saved price also needs its original timestamp, so a fresh page render doesn’t imply freshly updated data.

Usage counters and remaining allowance

The paid API’s /key endpoint reports the plan’s rate limit, monthly allocation, monthly usage, and remaining monthly credits. Its rate_limit_request_per_minute field states the plan’s rate limit; api_key_rate_limit_request_per_minute reports the rate configured for the key. Neither field reports how many requests remain immediately available during the current minute. An application needs request-timing records to manage that shorter window.

The response also exposes per-key usage and configured limits, distinct from account totals. The api_key_monthly_call_credit field reports that key’s configured monthly credit limit, while monthly_call_credit describes the plan’s allocation. When Enterprise key-level controls are enabled, reaching the configured key limit blocks calls only if that key’s hard limit is enabled. With it disabled, the key can exceed its configured monthly limit, subject to the account’s credit and overage settings. Credit monitoring needs the relevant account and key settings to avoid treating an account balance as permission for every key.

The Developer Dashboard provides a visual usage overview. Application logs add request timing and status details that monthly totals alone don’t contain.

Monthly exhaustion and overage eligibility

Exhausting the monthly allowance with overage disabled blocks further calls. Monthly credit usage resets on the first day of the next calendar month, regardless of billing cycle; waiting out a minute limit won’t restore that allowance. Eligible paid subscriptions can enable overage billing to continue beyond their included monthly allowance. Additional usage then creates overage charges on the following month’s invoice. Overage billing starts disabled by default. Enabling it addresses the monthly allowance restriction; the applicable minute rate still governs request pacing.

Cryptocurrency-paid API subscriptions don’t support overage billing, so a paid account doesn’t automatically qualify for that option. Crypto-paid subscriptions also don’t support mid-subscription upgrades or downgrades. Their included usage needs to fit the intended request schedule within those restrictions.

Capacity planning for the next refresh

A sustainable refresh schedule must fit both the busiest request period and the monthly credit budget for the data actually required. Monthly demand reflects successful calls per refresh and the number of scheduled refreshes. Minute demand includes every attempted request that shares the applicable limiter. Pagination, background data pulls, and simultaneous jobs can add calls beyond the visible page’s price updates.

A shared queue provides one place to coordinate traffic that uses the same limit. For paid REST access, workers using the same key or multiple keys from one source IP share the applicable minute limit. A schedule that consumes the full permitted rate leaves little room for retries or other work. Tracking successful calls separately from failed attempts makes the monthly forecast clearer without excluding failures from short-term traffic planning.

Batching and local reuse address duplicate demand. Keeping the same calls per refresh, a slower schedule reduces monthly credit demand. If the required schedule still exceeds the monthly budget or minute rate, the choice is more capacity or fewer requests.