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.
Without a key, an API request with the same image, options and quality as one from the last 10 minutes reuses that job and is not charged again, unless it failed. This protects clients that time out and resend. Send a new key to force a new job.
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.