Skip to main content
A submission response means the job was accepted. Read its status until the body says ready or error. HTTP 200 alone does not mean audio or stems are complete.

Generation polling

Use api from request setup. Define the polling function once, then pass a status request for each accepted job:
updateProgress is your UI callback. The intervals above are client choices, not a completion-time guarantee. Save taskId and songId as soon as submission returns. Generation status needs the same song/task pair.

Edit polling

The returned task kind matters: Separate uses extract, Layer uses lego, and Restyle uses cover. Candidate edits return take and audioUrl. Separation returns stems.

Generation and voice streams

These two streams use newline-delimited JSON, not SSE. Native EventSource cannot parse them or attach the needed account headers.
useAudio is your player callback. For a voice, use /api/voices/{id}/events with x-session-user-address; each line contains { voice, status, error? }. Reconnect a dropped read stream with the same IDs, or resume status polling. There are no public job cancellation or webhook registration routes. Aborting a fetch stops your client from waiting.

Error handling

A job can also report status: "error" inside a successful HTTP response. Handle both HTTP errors and job errors. The public submission routes do not expose an idempotency-key contract. Do not automatically resubmit after a timeout: you may create another charged job. Disable duplicate submit buttons, keep local operation state, and reconcile any known job IDs first. A failed generation admission can leave a song draft without audio; the owner can review or delete it through the library.