IP Rate Limit Exceeded
ip_rate_limit_exceeded429
Too many requests from your IP in one minute. Back off for 60 seconds and try again.
What this means
The IP address making the request hit our per-IP burst limit — currently 60 requests per minute across all endpoints. This limit applies before authentication is checked, so it catches misbehaving clients regardless of which API key (if any) they're using. The retry_after field is 60 by contract: wait one minute, then resume.
When you'll see this
- A development script ran an unthrottled loop and burned through 60 requests in a few seconds.
- A misbehaving client (yours or one of your customers) is retrying aggressively on a different error and hitting this ceiling.
- Multiple processes or containers behind one NAT'd egress IP are sharing the same per-IP budget.
- A scraper, bot, or proof-of-concept script ran without rate-limit awareness.
Learn more about how this works
We enforce two layers of rate limiting: a global per-IP limit (this error) and a per-account burst limit (burst_limit_exceeded). The IP limit exists to protect the platform from broken or hostile clients before they reach the authentication layer — it doesn't matter how high your account's plan is, an unauthenticated flood still gets cut off here.
In practice: well-behaved production code rarely sees this error. If you're seeing it from a server-side integration, something in your retry or fan-out logic is wrong. If you're seeing it from a browser-side integration, you almost certainly shouldn't be calling Asterwise directly from the browser — proxy through your own backend.
Example response
{
"success": false,
"error": "ip_rate_limit_exceeded",
"message": "Too many requests from this IP address. Please slow down.",
"details": [],
"retry_after": 60,
"doc_url": "https://docs.asterwise.com/reference/errors/ip_rate_limit_exceeded",
"request_id": "req_01HXYZABCDEFGH",
"timestamp": "2026-05-25T12:34:56Z"
}
- Stop the calling process. Wait 60 seconds. The IP limit window will clear.
- If a script is the culprit, add a
time.sleep(1)between requests as a temporary brake. - If multiple machines are sharing one egress IP, see "How to prevent this" — you need a real rate-limit strategy.
Always respect retry_after. The retry-after value is the floor, not a suggestion — retrying sooner just resets the counter on a server that's already telling you to slow down.
Python:
Production handler
- Python
- TypeScript
import httpx
import time
def call_with_rate_respect(url, headers, payload):
response = httpx.post(url, headers=headers, json=payload, timeout=30)
if response.status_code == 429:
body = response.json()
if body.get("error") == "ip_rate_limit_exceeded":
wait = body.get("retry_after", 60)
time.sleep(wait)
response = httpx.post(url, headers=headers, json=payload, timeout=30)
response.raise_for_status()
return response.json()
async function callWithRateRespect(url: string, headers: HeadersInit, payload: unknown) {
let response = await fetch(url, {
method: "POST",
headers,
body: JSON.stringify(payload),
});
if (response.status === 429) {
const body = await response.clone().json();
if (body.error === "ip_rate_limit_exceeded") {
const wait = (body.retry_after ?? 60) * 1000;
await new Promise((r) => setTimeout(r, wait));
response = await fetch(url, {
method: "POST",
headers,
body: JSON.stringify(payload),
});
}
}
if (!response.ok) throw new Error(`HTTP ${response.status}`);
return response.json();
}
Avoid this error by
- Use a request queue or rate limiter on your side. Even a basic token-bucket with 1 request/sec leaves plenty of headroom under our 60/min ceiling.
- Never call Asterwise from browser code. Proxy through your backend so all your users share your server's egress IP under your own rate logic, not ours.
- If you're processing a batch, parallelism is fine — but cap concurrent requests at 5-10 and add small jitter between them.
- For genuinely high-throughput integrations, talk to us before launch. We can advise on architecture that respects the ceiling without throttling your users.