Burst Limit Exceeded
burst_limit_exceeded429
Your account is sending requests faster than your plan's burst budget allows. Back off for 60 seconds.
What this means
Your API key authenticated successfully and the request is within your monthly call budget — but the per-minute request rate from your account exceeded what your plan's burst limit allows. The retry_after field is 60 by contract. Burst limits scale with plan: Sandbox 10/min, Builder 60/min, Launch 200/min, Scale 500/min.
When you'll see this
- A batch job is firing more requests per minute than your plan allows.
- A spike in user traffic temporarily pushed your aggregate request rate above the per-minute ceiling.
- Async parallelism on your side is fanning out wider than your plan's burst budget.
- A retry storm on a different error is amplifying request volume.
Learn more about how this works
Asterwise enforces two ceilings on your account: a monthly call budget (governs total volume) and a per-minute burst limit (governs spike shape). Both are real limits, but they exist for different reasons. The burst limit protects compute capacity — a flood of 5,000 requests in one minute strains the system even if you've paid for 50,000/month. The burst limit makes that flood land as a smooth curve instead of a vertical spike.
The most common gotcha: burst is per-account, not per-key. If you split traffic across multiple keys on the same account, you still share one burst budget. Multiple keys are useful for security boundaries (revoking one without affecting others), not for getting more headroom.
Example response
{
"success": false,
"error": "burst_limit_exceeded",
"message": "Too many requests per minute. Please slow down.",
"details": [],
"retry_after": 60,
"doc_url": "https://docs.asterwise.com/reference/errors/burst_limit_exceeded",
"request_id": "req_01HXYZABCDEFGH",
"timestamp": "2026-05-25T12:34:56Z"
}
- Pause the calling process for 60 seconds. The burst counter resets each minute.
- Lower the concurrency of your client (semaphore from 20 to 5, or similar).
- If this is happening regularly under expected load, your plan's burst tier may genuinely be undersized — review pricing to see what each tier allows.
Treat burst rejections as load-shedding signals. Back off, drain the queue, and resume — don't retry every request immediately, because they'll all hit the limit again.
Python:
Production handler
- Python
- TypeScript
import httpx
import time
from typing import Iterable
def process_batch(items: Iterable, url: str, headers: dict):
for item in items:
for attempt in range(3):
response = httpx.post(url, headers=headers, json=item, timeout=30)
if response.status_code == 429:
body = response.json()
if body.get("error") == "burst_limit_exceeded":
wait = body.get("retry_after", 60)
time.sleep(wait)
continue
response.raise_for_status()
yield response.json()
break
async function* processBatch(
items: Iterable<unknown>,
url: string,
headers: HeadersInit,
) {
for (const item of items) {
for (let attempt = 0; attempt < 3; attempt++) {
const response = await fetch(url, {
method: "POST",
headers,
body: JSON.stringify(item),
});
if (response.status === 429) {
const body = await response.clone().json();
if (body.error === "burst_limit_exceeded") {
const wait = (body.retry_after ?? 60) * 1000;
await new Promise((r) => setTimeout(r, wait));
continue;
}
}
if (!response.ok) throw new Error(`HTTP ${response.status}`);
yield response.json();
break;
}
}
}
Avoid this error by
- Match your client's concurrency to your plan's burst limit. Sandbox keys should run sequentially. Builder keys can comfortably parallelize 5-10 wide. Launch and Scale support meaningfully wider fan-out.
- For batch processing, use a semaphore or worker pool rather than
asyncio.gather()over thousands of items. Unbounded parallelism is the leading cause of this error. - Smooth your request shape with a token bucket. Even leaky-bucket pacing at your tier's limit minus 10% leaves headroom for occasional spikes.
- If you genuinely need higher burst capacity, the right move is upgrading the plan — not workarounds.