Skip to main content
The Platform API meters usage in credits rather than requests. Every REST request and every stream subscription has a price in credits, and your account pays it from a quota that refills in fixed windows. There are no separate daily, weekly or monthly limits.

​
Usage terms

Access to the Platform API is granted for personal, non-commercial use only. Commercial use, including redistribution or resale of data, is not permitted, and commercial licensing is not available at this time.

​
Quotas

  • Windows are fixed. The full quota comes back at once when the window resets, at the time in x-ratelimit-reset. Unused credits do not carry over.
  • Keys share one balance. Another key does not add credits: every key on the account spends the same quota.
  • REST and WebSocket are counted apart. Streams never spend REST credits, and REST requests never spend stream credits.
Every billed REST request costs at least 1,000 credits, so an account makes at most 100 requests per minute. For example, candle requests of up to 1,000 candles cost 1,000 credits each, so you can make 100 of them a minute; a request that returns 5,000 candles costs 5,000.

​
What REST requests cost

  • 1,000 credits is the floor. Three candles cost as much as a thousand, and a range with no data still costs 1,000.
  • TPO is priced per period. With mergeSessions=GROUP_BY_TYPE you get one profile per session type for every period at no extra cost.
  • No request costs more than 10,000 credits. A request returns at most 10,000 candles, 1,000 footprint profiles or 400 TPO profiles, see Request limits.
  • Rejected requests are free. A request answered with 400, 404 or 429 costs nothing.
Each endpoint page repeats its price under Cost.

​
What streams cost

The last column assumes every stream is of one kind. Mixed streams share the 1,000 credits: for example, 50 candle streams and 10 order books. A stream is charged per subscription, never per frame:
  • When data starts to flow. The price is taken once upstream data confirms the subscription. A stream that ends on a terminal upstream error before that costs nothing.
  • Again in every window it stays open. Right after each 300-second window resets, every open stream pays its price again. That makes the WebSocket quota a cap on how many streams you hold at once, and a stream opened shortly before a reset pays for both windows.
  • Again on every reconnect. A new connection is a new subscription.
The handshake needs the stream’s full price in remaining credits, otherwise it is rejected with 429. If the window is already spent when an open stream is due to renew, the stream ends with an error frame with code rate_limited, followed by a normal close.

​
Quota headers

Every authenticated REST response and every WebSocket handshake response carries the state of the window: On REST, x-ratelimit-remaining already includes the price of the request it came with. On a handshake it is read before the stream is charged, because the price is taken once data starts to flow.

​
When the quota runs out

A REST request that the remaining credits cannot cover is rejected with 429, and a Retry-After header gives the seconds left until the window resets:
Wait for the reset instead of retrying at once: until then, every attempt gets another 429. The rejection itself costs nothing. A WebSocket handshake that fails on credits answers the same way, with 429 and Retry-After. To stay under the quota, watch x-ratelimit-remaining as you go and spread heavy requests across windows: ten requests for 10,000 candles each spend a whole minute of REST credits.

​
Request limits

A single REST request is capped: A range over the cap is rejected with 400 and code too_much_data before anything is billed, and the message names the cap it hit. Narrow from and to, use a longer timeframe, or split a long history into several requests. It is never a rate limit, so sending the same request again will not help. A candle limit above 10000 is different: that is a bad parameter value rather than an oversized range, and it comes back as invalid_argument.

​
History depth

Candles cover the full history we hold for each security. Volume footprint and TPO reach back less far. Volume footprint keeps a fixed number of calendar days per timeframe, counted back from the security’s newest candle, which is now while it trades: A from older than the limit is trimmed rather than rejected: the response starts at the limit, and its first profileStart is the real start. A range that ends before the limit comes back empty and still costs 1,000 credits. On the live footprint stream, a rangeTruncated frame tells you the limit moved since forward. TPO has no depth limit per timeframe, only the 400-profile cap per request. Both start on 29 May 2026, the day we began collecting the data they are built from; weekly profiles start with the week that contains it, on 25 May. Where a limit above reaches further back, history starts on that date. There are no plans to backfill earlier periods: that would take historical tick data, which not every exchange makes available.