Rate limits & credits

Two separate budgets

Requests per minute, by plan

How the window works

A 60-second sliding window per API key — not a fixed clock minute. Sixty requests at 10:00:59 and sixty more at 10:01:01 will trip the limit on a 60/min plan, because the window looks back 60 seconds from now, not to the top of the minute.

Sandbox endpoints under /v1/demo/ are limited separately, by IP, at 30 requests/minute — they need no key, so there is no key to meter.

When you hit it

HTTP/1.1 429 Too Many Requests
Retry-After: 60
X-RateLimit-Limit: 30
X-RateLimit-Remaining: 0
Content-Type: application/problem+json

Retry-After is in seconds. Honour it rather than retrying immediately — a tight retry loop keeps the window full and you stay limited.

Staying under it

• Poll on the data's clock, not yours. Racing prices move fastest near jump; there is nothing to gain from polling a market every second that only updates every few.
• Ask for more per call. One /v1/racing/next-to-go returning many races costs 2 credits or 3 credits or 4 credits; fetching each race separately costs far more of both budgets.
• Cache the slow-moving things. /v1/sports changes rarely.
• Check freshness before refetching. Sports markets carry a quality object with age_seconds — if the price you hold is as fresh as the one you would fetch, skip the call.
• Back off on 429 and 5xx, immediately on 402. See errors for a worked retry loop.

Need a higher ceiling?

If your workload genuinely needs more throughput than Scale's 2000/min, get in touch rather than sharding across keys — we would rather size a plan to the use case.