Suno API limits: the four that bite
Most "the API is unstable" reports are one of four limits being hit in the wrong order. Name them and the fix is usually a two-line change.
The four limits
| Limit | What it looks like | What to do |
|---|---|---|
| Request rate | 429 responses under burst load | Exponential backoff and a queue; do not retry immediately |
| Render time | Minutes between submit and audio | Poll every 3-5 seconds; set client timeouts in minutes, not seconds |
| Concurrency | Throughput plateaus no matter how many requests you send | Cap parallel generations; scale by queue depth, not by request rate |
| Account quota | 402 or balance errors mid-batch | Check the balance endpoint (free) and alert before a batch starts |
Why a timeout is not a failure
A client timeout means you stopped waiting; it does not mean the order was rejected. Treat it as "still running": query the task, and only resubmit if the task reports a terminal failure. Resubmitting on timeout is the number one cause of duplicate charges.
A retry policy that works
- Retry reads freely (status, downloads) - they are free and idempotent.
- Retry writes only after checking the task state.
- On 429, back off 1s → 2s → 4s and reduce concurrency.
- Log the task id for every generation so a failed batch can be reconciled later.
常见问题 / FAQ
Is there a hard daily cap?
Platforms set per-account quotas; the balance endpoint tells you what is left, and it is not billed.
How many generations can I run at once?
Start with a handful in parallel and watch the failure rate; increase until 429s appear, then back off.
Do download requests count against limits?
They are read-only and not billed, but still subject to normal rate limiting.
Is there an official Suno API? What you can actually use, and what it costs.
注册只需要邮箱，一次生成 0.6 元出 2 首，MP3 与 WAV 下载不限次。
See the integration docs
注册只需要邮箱，一次生成 0.6 元出 2 首，MP3 与 WAV 下载不限次。