Loading documentation…
Loading documentation…
Bound retries and distinguish terminal outcomes from temporary failure.
| Contract | Limit |
|---|---|
| Sizes | 64, 128, 256, 512; at most four unique sizes |
| Formats | WebP and AVIF; at most two unique formats |
| Variants | At most eight combinations, recipe r1 |
| Batch | 1–100 entries with unique keys of 1–100 characters |
| Idempotency key | At most 200 characters |
| Source URL | At most 4096 characters plus admission policy |
| Alias | Exact name up to 512 characters; class/instance decimal strings up to 30 digits |
These request limits are not a capacity or availability promise. Shared Service Account request limits, Customer traffic safety, preparation resource budgets and deployment capacity also apply. Do not infer throughput from a batch-size limit.
| Response | Handling |
|---|---|
| 401 | Check or rotate the Credential on your server |
| 403 | Check operation scope, workload and Billing product access |
| 404 | Check selector/alias or owning workload; do not fetch a live catalog as an automatic fallback |
409 image_binding_required | Configure an active current binding |
409 idempotency_replay | Follow the retained status link |
409 image_variants_not_requested | Resolve the intended variant selection |
| 422 | Correct request fields, duplicates or unsupported format selection |
| 429 | Respect Retry-After; distinguish workload limit from Customer traffic safety |
| 503 | Preserve operation identity and retry within a bounded deadline |
A per-variant terminal preparation error can appear inside HTTP 200. Inspect settled and each variant. Record request IDs for support, excluding credentials and sensitive URLs. Avoid retrying invalid selectors or repeatedly resubmitting accepted work. See executable clients for status-link and deadline handling.