Request body
| Parameter | Type | Behavior |
|---|---|---|
| model | string · required | Exact model and operation ID. |
| input | object · required | Validated against that model’s schema. |
| output_count | integer · default 1 | Images/videos only; 1–4 target items. |
| fallback | boolean · default false | Authorizes eligible official fallback. |
| max_credits | non-negative integer · optional | Maximum total reservation you accept. |
Planned live acceptance
When live execution is enabled, successful acceptance atomically records the operation, result items, credit reservation, and durable scheduling record. HTTP 202 means work is accepted, not that a model has finished.
With output_count=4, you receive one task ID containing four stable items. The worker schedules each item within account and provider limits. There is no guarantee that all four start simultaneously.
During this build, real provider execution is not connected. A request must not manufacture a successful model output or a completed paid generation.
Planned idempotent acceptance
Once live task acceptance is enabled, send Idempotency-Key and retain it with the input. In this build, POST /v1/tasks rejects live execution before creating an operation, so the header does not yet produce a stored operation. Reusing it with the same input refers to the original operation; changing quantity, fallback, or the credit cap should return a conflict. Deliberately generating again requires a new key and a new paid operation.