Errors
429 - rate limited (per-token cap)
What happened
The request exceeded an existing request budget. Services sharing the same credential may contribute to the same limit.
- Read the retry guidanceInspect Retry-After and the reported rate limit.
- Reduce request pressureWait and lower concurrency or request frequency.
- Retry within a limitUse bounded backoff for reads; reconcile uncertain writes first.
- Check recoveryConfirm requests succeed without continuing a tight retry loop.
Request that triggers it
Any request after the per-token cap is hit. -i shows the headers.
curl -i -X POST "https://$OC_HOST/v1/tenants/$OC_TENANT/sql" \
-H "Authorization: Bearer $OC_TOKEN" \
-H "Content-Type: application/json" \
-d '{"sql": "SELECT id FROM shop.products LIMIT 1"}'Read the response
HTTP/1.1 429 Too Many Requests
Retry-After: 7
Content-Type: application/json
{
"error": "rate_limited",
"message": "API key has exceeded its per-second request quota",
"retry": true,
"retry_after_seconds": 7
}Fix the request
- Read Retry-After or the retry delay in the response.
- Wait before a bounded retry.
- Reduce request concurrency or batch supported operations.
- Review the configured quota if the workload regularly exceeds it.
Keep in mind: For uncertain writes, reconcile the previous outcome before retrying. Do not create extra credentials to bypass the limit.
Common causes
- Backfill script with no per-request delay.
- One token shared across many services that each assume they have the full budget.
- A retry loop that doesn't honour
Retry-Afterand amplifies the spike. - Multiple replicas of a worker that all woke up after a deploy and started together.
- A frontend that fires a fetch per keystroke instead of debouncing.
Continue
See error handling and retries, or return to error examples.