Credits and usage
Credits measure your API usage. After your account moves to credit billing, REST requests, delivered WebSocket data messages and delivered Server-Sent Events (SSE) share one account balance across all your API keys.
When credit billing starts
Migration rolls out from 1 November 2026, at your account's next eligible allowance reset. Your dashboard shows your transition date when confirmed. Until your account switches, its existing request allowance and billing continue, and streaming message credit charging has not started.
Existing paid request add-on access is preserved through its paid-through date. Accounts with these add-ons move at an eligible allowance boundary after that access ends. Request-volume add-ons are being replaced by prepaid credits.
REST credit costs
| Successful response | Credit cost |
|---|---|
| Standard single-object response | 1 credit per request |
| Collection, history, candle or indicator response | 1 credit per 500 returned items, rounded up, with a minimum of 1 credit |
Bulk coin download (/v2/bulk/coins) | 5 credits per request |
Search suggestions (/v2/search-suggestions) | 1 credit per request |
Coin statistics (/v2/stats/coins) | 1 credit per request, regardless of how many coins the statistics cover |
| Authentication, permission, validation, rate-limit or server error | 0 credits |
For item-based endpoints, the cost is max(1, ceil(returned items / 500)). Count the main collection returned by the endpoint; nested fields do not count as additional items. The requested limit alone does not determine the final charge. Each page is a separate request.
| Items returned in one collection response | Credits |
|---|---|
| 0, 100 or 500 | 1 |
| 501 or 1,000 | 2 |
| 5,000 | 10 |
REST requests temporarily reserve credits before processing. The reservation can exceed the final cost when the number of returned items is not yet known. Unused reserved credits are released after completion. Available balance already excludes reservations.
WebSocket and SSE credits
Delivered data messages consume credits at your plan's published message rate. See message pricing for your rate. A message can cost a fraction of a credit. For example, at a rate of 0.1 credit per message, 1,000 delivered messages cost 100 credits.
Opening a connection, heartbeats, acknowledgements and error messages cost no credits. Receiving the same data on multiple connections counts as separate deliveries. Choosing a slower supported throttle can reduce the number of messages you receive.
Streaming is available on all plans, including DEX streaming. Your plan's connection limits and minimum update interval still apply. REST DEX endpoint access follows your plan permissions.
Included and prepaid credits
Your plan includes a credit allowance. Included credits are used first and expire at the end of their allowance period. Prepaid credits are separate from your plan allowance and are valid for 12 months.
Eligible paid accounts can buy prepaid credits in multiples of 100,000 credits. The dashboard shows the current price and applicable taxes before you confirm. Credits become available after payment is confirmed. Buying credits does not unlock endpoints or increase rate or connection limits.
Automatic top-up
You can enable automatic top-up in your dashboard and choose the available-balance threshold, refill amount and monthly automatic purchase cap in credits. When your available balance falls below the threshold, an authorized purchase uses your default payment method. The cap uses a UTC calendar month and includes pending and successful automatic purchases; manual purchases do not count toward it.
Automatic top-up is optional. Payment takes time, so choose a threshold that leaves room for your expected usage. A failed payment adds no credits. Top-up pauses when payment needs attention or the price exceeds your authorization. You can disable future top-ups in the dashboard.
Usage dashboard and CSV exports
Use the Usage dashboard to compare REST and streaming usage, filter by API key and date, and export CSV. Requests and delivered messages are separate counts; both contribute to credit usage.
CSV exports show the UTC date and time, API key name, readable operation name, transport, credits, overuse credits, requests, messages and metering errors. Credit amounts are decimal credits, not internal accounting units. Historical usage can appear after the live balance updates. Usage logs may summarize multiple calls or messages.
Overuse credits describe streaming delivered beyond the funded balance before an exhaustion disconnect. They are reported separately and are not deducted from a later top-up.
REST response headers
| Header | Meaning |
|---|---|
x-credit-cost | The request's credit cost, as a decimal credit amount |
x-credits-remaining | The available balance reported for this request; concurrent usage can change it |
x-credit-accounting-status | Whether credit accounting was applied; headers can differ when accounting is unavailable |
When credits run out
A REST request that cannot reserve enough credits returns HTTP 429 with code: "credits_exhausted". This differs from a short-term rate limit: waiting a few seconds does not replenish credits. Wait for your allowance reset or add prepaid credits.
A WebSocket can close with code 4008 and reason credits_exhausted. SSE streams can also close when credits run out. Avoid continuous reconnect attempts until credits are available. Streaming accounting is batched, so the balance and disconnect may follow delivery with a short delay.
Credit allowances do not replace endpoint permissions, daily preview limits, request rate limits or streaming connection limits. See rate limits and errors when handling rejected requests.