Limits & retries
Bounded work keeps the service responsive and the bill predictable.
| Limit | Initial service |
|---|---|
| Image input | 22 MB/file; 24 MB total multipart request; JPG, PNG or WebP |
| Resolution | 12 MP free; 50 MP with credits |
| Free allowance | 5/day per browser/account and shared IP; shared service capacity also applies |
| Free queue | 2 pending jobs per owner; 15-second maximum wait before processing starts |
| Paid queue | 100 pending jobs per account; 5-minute maximum wait |
| Submission rate | 60/min with API key; 30/min in browser |
| Batch export | 1–100 finished images; up to 300 MB |
| Retention | Image files: 1 hour; detailed usage and idempotency records: 7 days |
| Synchronous API wait | 55 seconds; then 202 with job ID if still processing |
| Download format | PNG, JPG, WebP; API ZIP with color and alpha; Base64 JSON up to 16 MB output |
Retries and idempotency
Use Idempotency-Key on image submissions. Reuse that key only with identical source and options. A different payload returns 409. A completed but expired result returns 410. After a failed job, use a new key for an intentional new attempt.
On 429, wait for the seconds in Retry-After and add random jitter. On a network timeout, check the original job or repeat the original request with the same key. Do not start a second charge while the first job is running.
Scaling up
These are current limits, not a throughput guarantee. For larger workloads, submit jobs gradually, respect rate limits and wait for each result before downloading.