POST /v1/music/generations creates a public TokenLab task and returns id / task_id, status, and usually poll_url. Your application should store that task identity, show task state, and poll until a terminal status.
Choose The Workflow
Query the current model catalog before shipping a hard-coded model list:
suno_music for music generation and include mv with an official Suno model version such as chirp-v4. For lyric-only flows, send action: "LYRICS" with a model whose model details documents lyric generation and omit mv. Treat model IDs as public TokenLab IDs, not as a guarantee that provider-specific fields are model details fields.
Create A Music Task
Poll For Completion
Usepoll_url first. If your client needs a fixed route, call GET /v1/tasks/{id} with the returned id or task_id.
Response Shape
The create response is a task record, not the final audio:status is completed. Failed tasks return status: "failed" with error.
Expected public statuses are pending, processing, completed, and failed. A completed music task can include audio_url, video_url, title, lyrics, and normalized metadata. Store final URLs in your own database so the user can reopen the result without restarting generation.
UI And State Handling
- Show a pending state immediately after task creation.
- Poll every
5-10sfor long tasks, then stop oncompletedorfailed. - Do not display a final player until the task is
completedand anaudio_urlexists. - For lyric-only tasks, render text output separately from audio tasks so users understand what they are buying.
- On refresh, resume from the stored
task_idinstead of creating a new task.
Billing And Reconciliation
Music tasks can reserve an estimated amount at create time and settle after the terminal status is known. Storerequest_id, task_id, model, endpoint, and billing_transaction_id when it appears. Use Management API usage records for reconciliation instead of provider task IDs.