Error: rate_limited
Too many requests in the rate-limit window. The response includes retry_after — honor it.
What it means
Rate limits protect the service. When exceeded, the API returns 429 with an error and a retry_after value in seconds.
Common causes
An agent in a tight retry loop hammering evaluate — exactly the pattern a velocity rule would stop.
A misconfigured client that re-sends immediately without backoff.
How to fix
Read retry_after and wait that long before retrying.
Add exponential backoff to your client.
Ironically, the fix for agent-side loops is a sipi.bot velocity rule — but the API's own rate limit applies too.
At a glance
| Field | Value |
|---|---|
| HTTP status | 429 |
| Error code | rate_limited |
| Response shape | {"error": "rate_limited", "retry_after": 60} |
| retry_after | Seconds to wait (varies by route) |
Example
curl -X POST https://sipi.bot/v1/transactions/evaluate \
-H "Content-Type: application/json" -d '{"amount": 10, "merchant": "demo"}' # ...burst...
HTTP/1.1 429
{"error": "rate_limited", "retry_after": 60}Wait retry_after seconds, or add backoff.
FAQ
What is retry_after?
The number of seconds to wait before retrying. Different routes use different windows (e.g. 60s and 3600s).
Does 429 count as spend?
No — a rate-limited request is rejected before evaluation. Nothing is charged.
How do I avoid tripping it?
Backoff + batching. If your agent retries aggressively, that's also what a sipi.bot velocity rule is for.
Related
Stop the next $12,400 night.
One API call (or MCP tool) in front of every agent transaction — APPROVED, BLOCKED, or FLAGGED, deterministic, ~5 ms, fully logged.
See plans — from $99/mo Try a live check