Create an asynchronous generation task
Validates the model input, reserves the estimated charge, chooses an available deployment, and creates a task in queued state. HTTP 202 means the task was accepted; it does not mean generation has completed.
An Idempotency-Key is optional but strongly recommended. For the same account and the same API key, repeating a key with the same normalized model, input, and callback URL within 24 hours returns the original task and does not reserve funds twice. A sibling API key cannot replay the mapping: it receives 409 Conflict without the original task ID. Reusing the key with different request semantics also returns 409 Conflict. Callbacks are optional and are validated against private/loopback destinations before acceptance.
Request
- Base URL: https://api.spicyapi.ai
- URL: https://api.spicyapi.ai/api/v1/jobs/createTask
- Auth: HTTP bearer
Query parameters
Seconds to hold the connection open waiting for the task to reach a terminal state, so you do not have to write a polling loop for the first call. Values above 60 are clamped to 60; anything that is not a positive integer is ignored rather than rejected, because a typo in an optimisation parameter should not fail a generation that would otherwise succeed.
Reaching a terminal state within the budget returns 200 with the same task record recordInfo returns. Running out of budget returns the ordinary 202 — identical to omitting wait — and you poll from there. Disconnecting stops the wait and nothing else: the task keeps running and is billed as usual.
The ceiling stays well under the 100-second edge timeout on purpose. Past that line the connection is cut by the CDN rather than by us, and the caller gets a 524 carrying neither the task ID nor any resumable state — while the task exists and the funds are already held.
Headers
Stable key for one logical task submission; retained for 24 hours per account and bound to both the submitting API key and normalized request fingerprint. A sibling key receives 409 without the original task ID.
Retention for this one task, in whole seconds. It applies to both the generated outputs and the stored request text. The effective value is always min(header, account setting, platform maximum): a request can only shorten retention, never extend it. 0 is valid and means the outputs are removed as soon as the task reaches a terminal state. Values that cannot be applied never fail the request: a negative number is clamped to 0, a value above the ceiling is clamped to the ceiling, and a value that is not a decimal integer is ignored so the account setting applies. The effective result is always reported back in retention on the task record. Accepted by createTask and stream. retry inherits the source task's effective value and ignores this header, so one task family never ends up with two different expiry times. quote does not accept it because it does not create a task.
Request body
Response
Returned only when wait was supplied and the task reached a terminal state inside that budget. The body is the task record, identical in shape to recordInfo. A terminal state is not necessarily a success - check data.state.
Changes
No recorded changes to this operation across all 1 revision of this API.