Skip to main content
多くのメディアエンドポイントは非同期です。作成リクエストは作業を開始し、公開TokenLabタスクのIDを返します。アプリケーションは、そのタスクが最終ステータスに達するまでポーリングします。上流タスクのURL、ルーティングID、またはプロバイダーのコールバック動作に基づいて顧客のワークフローを構築しないでください。

公開タスク契約

作成レスポンスには以下が含まれる場合があります: /v1/tasks/{id}は、公開非同期メディアジョブのための標準的な固定ステータスエンドポイントです。互換性のためにメディア特有のステータスルートが存在する場合がありますが、新しい統合はpoll_urlまたは/v1/tasks/{id}を優先するべきです。

推奨フロー

  1. ユーザーリクエストを検証し、明示的なmodelを持つ作成呼び出しを送信します。
  2. UIに制御を戻す前に、id / task_idpoll_url、エンドポイント、モデル、ユーザーID、および自分のジョブIDを保存します。
  3. 長時間実行されるメディアタスクのために、毎5-10秒ポーリングします。
  4. タスクがcompletedまたはfailedになるまで停止しません。
  5. completedの場合、メディア特有の結果フィールドを読み取り、最終URLまたはメタデータを保存します。
  6. failedの場合、公開エラーを保存し、新しいユーザー可視ジョブとしてのみ再試行を提供します。

ポーリングの例

期待される公開ステータスはpendingprocessingcompleted、およびfailedです。キャンセルされたタスクはfailedとして表され、cancelled: trueおよびcancellation_status: "cancelled"が含まれるため、古いステータス処理が機能し続けます。

クライアント再試行ルール

ネットワークタイムアウトは、重複ジョブの最も一般的な原因です。このルールを使用してください: ブラウザが更新されたり、ステータスポーリングが失敗したからといって、2回目の作成リクエストを送信しないでください。

請求と決済

非同期ジョブは、作成リクエストが受け入れられたときに推定額を予約できます。最終的な決済は最終ステータスの後に行われます。利用可能な場合、タスクステータスレスポンスはbilling_transaction_idおよびX-Billing-Transaction-IDヘッダーを公開できます。 調整のために、これらの識別子をログに結合します:
  • 作成リクエストからのrequest_id
  • タスクからのtask_id / id
  • 存在する場合のbilling_transaction_id
  • 自分のユーザーID、プロジェクトID、またはジョブID。

キャンセル

DELETE /v1/tasks/{id} は意図的に対象を絞っています。選択されたタスクでキャンセルが利用できる場合、seedance-1.5-proseedance-2.0seedance-2.0-fast などのキュー中の Seedance 動画タスクに対応します。 サポートされていないタスクは400 unsupported_task_cancelを返します。すでに実行中または最終のタスクは409 task_not_cancellableを返します。キャンセルUIは「キャンセルをリクエスト」として構築し、保証された停止ボタンではなくします。

トラブルシューティング

サポートパケット

サポートに連絡する際は、request_idtask_idbilling_transaction_id(存在する場合)、エンドポイント、モデル、タイムスタンプ、およびサニタイズされたリクエスト形状を含めてください。サポートが赤actedサンプルを要求しない限り、APIキー、プライベートメディア、署名付きURL、または完全なプロンプトを含めないでください。

APIリファレンス