Limits and retries
Keep batches, polling, and account capacity within the service contract.
Account and request limits
| Operation | Current bound |
|---|---|
| Queued or processing downloads per account | At most 10, or a lower configured ceiling |
| New ordinary download requests | 20 per minute per account |
| Job status reads | 300 per minute per account |
| HTTP batch or playlist download selection | 1 to 10 items |
| Saved playlists | 5 per account |
| Saved links | 50 per playlist |
| Items in an Instagram post result | Up to 50 |
| Private signed URL lifetime | Normally 900 seconds; operator-configurable |
Keys on the same account do not multiply these allowances. The authenticated artifact/download allowance defaults to 5 GiB, subject to worker and deployment ceilings. A post's byte limit is shared across its collection. These bounds are not a promise of sustained bandwidth or weighted partner scheduling.
Polling
Poll jobs about once every two seconds and stop on a terminal status. Use bounded waiting in a UI or service. Use SSE when it fits your client, and fall back to status lookup after a reconnect.
Retry safely
For 429 or a temporary 5xx, wait and increase the delay between retries. Honor Retry-After when supplied. Use jitter when several workers could retry together.
For a timed-out individual submission, keep its Idempotency-Key. Reusing that key for a different body returns 409. Do not blindly resubmit batches, because HTTP batch creation does not have the same idempotency contract.
An expired key is not repaired by retrying it. A permanent source failure, invalid request, or ownership failure also needs a change rather than an immediate retry loop.