A 429 status code means you have sent more requests than your plan allows in the current time window. The response looks like this:
{
"error": "Too Many Requests",
"retryAfter": 9
}retryAfter is the number of seconds until the window resets and you can send requests again.
How the rate limit works
Each plan allows a number of requests per 15-second window. The window starts with your first request. Once it expires, your counter resets to zero.
Free: 1 request per 15 seconds
Basic: 5 requests per 15 seconds
Pro: 30 requests per 15 seconds
Expert: 75 requests per 15 seconds
A bulk request counts as one request, no matter how many indicators it calculates.
Too many constructs
You can also get a 429 from POST /bulk or POST /bulk-candles if a single request contains more constructs than your plan allows (1 on Basic, 3 on Pro, 10 on Expert):
{ "error": "Too many constructs. Your plan allows 3 construct(s) per bulk request." }Waiting won't fix this one. Split the request into smaller ones, or upgrade your plan.
Check your usage in the response headers
Every response includes three headers you can use to stay under the limit:
X-RateLimit-Limit: how many requests your plan allows per window.X-RateLimit-Remaining: how many requests you have left in the current window.X-RateLimit-Reset: seconds until the current window resets.
How to avoid 429 errors
Use bulk queries. Combine indicators, symbols and timeframes into one request instead of many single calls.
Wait when you get a 429. Pause for
retryAfterseconds before retrying. Retrying straight away in a tight loop keeps triggering 429s.Spread out your requests. If you poll on a schedule, space calls evenly across the window rather than sending them all at once.
Use WebSocket streaming for live data. Instead of polling the same indicator over and over, subscribe once and receive updates as they happen.
Upgrade your plan if you consistently need more requests.