Skip to main content
GET
Get generation task status

Task Lifecycle

Long-running model execution follows:
A successful submit response means the request was accepted. It does not mean generation has finished. Use MCP poyo_submit_job and poyo_check_job, or the CLI:

Normalized statuses

The REST generation API continues to expose its existing raw status values. MCP and the CLI normalize them without changing the stored task.

Resume safely

Keep the task_id in durable application state or working notes. If a process or agent session is interrupted, query the existing task rather than submitting and paying for a replacement.

Polling

When a response includes poll_after_seconds, wait at least that long before the next status check. Otherwise, use bounded exponential backoff with jitter. Honor Retry-After after a 429 response. Stop only on succeeded, failed, or your own timeout; a local timeout does not cancel the remote task.
For production applications, prefer a signed webhook when the native generation API supports it. A webhook reduces status traffic, but the receiver should still fetch or validate the task before trusting output.

Result handling

On success:
  1. Record the model ID, task ID, final status, and charged credits.
  2. Validate the expected output fields.
  3. Download generated files to storage you control before temporary URLs expire.
  4. Treat repeated webhook deliveries and status reads as normal.
On failure, keep the task ID and normalized error. Retry only when the error is transient. Submission retries are not deduplicated, so confirm whether the original request created a task before resubmitting.
poyo_run_model waits for at most 30 seconds. If the work is still running, it returns the task ID and poll_after_seconds instead of failing the generation.

Authorizations

Authorization
string
header
required

Bearer authentication header of the form Bearer <token>, where <token> is your auth token.

Path Parameters

task_id
string
required

Response

200

Task status and outputs