Platform API error
rate_limited
rate_limited (HTTP 429) means the API key used its per-minute request allowance. Wait for Retry-After, then retry or move to a larger plan.
Updated November 6, 2026
- HTTP status
- 429
- Code
rate_limited
Returned when
- More requests in a minute than the plan allows: Sandbox 10, Starter 60, Growth 300, Scale 1,200. The answer carries Retry-After, X-RateLimit-Limit and X-RateLimit-Remaining.
What to do
- Honour Retry-After and back off with jitter; spread bursts, or move to a larger plan.
Example answer
HTTP/1.1 429
content-type: application/json
{
"error": {
"code": "rate_limited",
"message": "Too many requests for this key."
}
}Related errors
- quota_exceeded The day's call allowance and any call packs are used.
What it means
rate_limited is the error code the OneLifeVibe Platform API returns with HTTP status 429 when the API key has used its per-minute request allowance. The request was rejected because that key had already sent as many requests as its plan allows in the current minute.
The allowance is per minute and per key: Sandbox 10 requests, Starter 60, Growth 300, Scale 1,200. Every call that carries the same key counts toward the same allowance.
The 429 response carries Retry-After, X-RateLimit-Limit and X-RateLimit-Remaining headers. The message is typically Too many requests for this key. Errors use one shape, {"error":{"code":"…","message":"…","hint":"…"}}, and codes are stable while messages are not.
Why you are seeing it
Bursts are the usual cause. A loop that fires calls without pacing, several workers sharing one key, or an instant retry after a failed request can push a key past its per-minute allowance in a few seconds.
Fan-out patterns do it too. Fetching a list and then requesting details for every item in parallel turns one user action into dozens of calls. A Sandbox key at 10 requests per minute reaches its ceiling quickly during testing.
If you wait out Retry-After and the next attempt is still rate_limited, another client is probably sending on the same key. The X-RateLimit-Remaining header shows how much of the allowance was left when the response was built.
How to fix it
Read Retry-After from the 429 and wait at least that long before sending again. Retrying immediately does not use up allowance, but it keeps the pressure on, and the allowance only refills with time.
Add jitter. If five workers all sleep the same number of seconds and retry together, they collide again; a random offset spreads the retries out. Cap the retries so a persistent 429 surfaces instead of looping.
Pace steady traffic across the minute instead of sending it all at once, and avoid re-requesting data you already hold. If normal volume keeps you at the ceiling, move to a larger plan: Starter allows 60 requests per minute, Growth 300, Scale 1,200.
Handling it in code
Match on the code field, never on the message. Compare against rate_limited exactly; the error shape {"error":{"code":"…","message":"…","hint":"…"}} is the same across the API.
On a 429, read Retry-After and X-RateLimit-Remaining from the headers, sleep for Retry-After plus a small random jitter, then retry. Keep a retry ceiling so a key that stays limited fails loudly rather than hanging.
Log the key, the endpoint and X-RateLimit-Remaining at the moment of failure. That separates one hot endpoint from a saturated key, which is the difference between pacing a single call path and changing plans.
Questions
What are the per-minute rate limits for each plan?
Sandbox allows 10 requests per minute, Starter 60, Growth 300 and Scale 1,200. The limit applies to each API key, and the 429 response reports it in X-RateLimit-Limit.
What does the Retry-After header tell me?
Retry-After tells you how long to wait before sending the next request on that key. Read it from the 429 response and wait at least that long, adding jitter when several workers retry.
Is rate_limited the same as quota_exceeded?
No, they are separate codes. A key that has used its per-minute allowance gets rate_limited with HTTP 429, so match on the code value rather than the message or status alone.
Keys, plans and usage live in the console: rotate keys, add webhook endpoints, see the last 30 days.
Written from the OneLifeVibe tool registry and platform configuration, and checked automatically before publishing. Something wrong? Tell us.