POST /v1/music/generations は公開されたTokenLabタスクを作成し、id / task_id、status、通常はpoll_urlを返します。アプリケーションはそのタスクの識別子を保存し、進行状況を表示し、最終的なステータスになるまでポーリングする必要があります。
ワークフローの選択
ハードコーディングされたモデルリストを出荷する前に、現在のモデルカタログをクエリします：
suno_musicを使用し、chirp-v4などの公式Sunoモデルバージョンをmvに含めています。歌詞のみのフローの場合、歌詞生成を文書化したモデルと共にaction: "LYRICS"を送信し、mvは省略します。モデルIDは公開されたTokenLab IDとして扱い、プロバイダー固有のフィールドが対応状況フィールドであることを保証するものではありません。
音楽タスクの作成
完了のポーリング
まずpoll_urlを使用します。クライアントが固定ルートを必要とする場合は、返されたidまたはtask_idでGET /v1/tasks/{id}を呼び出します。
レスポンス形式
作成レスポンスは最終音声ではなく、ポーリング可能なタスクレコードです。status が completed になるまで含まれません。失敗したタスクは status: "failed" と error を返します。
期待される公開ステータスはpending、processing、completed、およびfailedです。完了した音楽タスクにはaudio_url、video_url、title、lyrics、および正規化されたメタデータが含まれる場合があります。最終的なURLは自分のデータベースに保存し、ユーザーが生成を再開せずに結果を再度開けるようにします。
UIと状態管理
- タスク作成後すぐに保留状態を表示します。
- 長いタスクの場合は、
5-10秒ごとにポーリングし、completedまたはfailedで停止します。 - タスクが
completedであり、audio_urlが存在するまで最終プレーヤーを表示しないでください。 - 歌詞のみのタスクの場合、ユーザーが購入している内容を理解できるように、オーディオタスクとは別にテキスト出力をレンダリングします。
- リフレッシュ時には、新しいタスクを作成するのではなく、保存された
task_idから再開します。
請求と調整
音楽タスクは作成時に推定額を予約し、最終ステータスがわかった後に決済できます。request_id、task_id、モデル、エンドポイント、およびbilling_transaction_idが表示されたときに保存します。プロバイダーのタスクIDの代わりに、管理APIの使用記録を調整に使用します。