Skip to main content

​
簡短回答

根據當前公開的 Seedance 2.0 API 文件，介面提供了“建立任務”和“查詢任務狀態”能力，但沒有提供任務取消或刪除介面。 建立任務成功後，介面會返回一個 task_id。客戶端超時、網路中斷、關閉網頁或停止輪詢，都不能作為“任務已經取消”的依據。遇到這類情況，應先查詢原任務狀態，再決定是否重試，避免重複建立任務。

​
當前公開介面和任務狀態

Seedance 2.0 當前使用非同步任務介面： 任務狀態通常按以下流程變化：
  • queued：任務已建立，正在排隊。
  • running：任務正在處理。
  • succeeded：影片生成成功。
  • failed：任務處理失敗。
  • expired：任務超過有效執行時間，進入過期狀態。
生成成功後，影片地址位於：
該地址是臨時簽名連結，當前文件說明有效期約為 24 小時。任務成功後應及時下載並儲存影片。
當前公開 API 文件未提供任務取消介面。停止本地指令碼或停止輪詢，只會停止客戶端繼續查詢，不能證明服務端任務已經被撤回。

​
任務提交後應該怎麼處理？

​
第一步：儲存 task_id 和請求資訊

建立請求成功後，應立即儲存返回的 task_id。 同時建議記錄以下資訊：
  • 模型名稱；
  • 提示詞或提示詞摘要；
  • 影片時長、解析度、比例等主要引數；
  • 提交時間；
  • request ID；
  • 業務系統中的業務 ID。
這些資訊可以用於後續查詢任務、定位問題和核對賬單。

​
第二步：查詢原任務狀態

Seedance 2.0 是分鐘級非同步任務。當前 API 文件建議：
  • 提交後等待約 20–30 秒，再進行第一次查詢；
  • 後續每隔 10–20 秒查詢一次；
  • 不要因為短時間內沒有返回影片就立即重新提交。
查詢任務示例：
請將以下佔位符替換為實際值：
  • YOUR_TASK_ID：建立任務介面返回的任務 ID；
  • YOUR_API_KEY：API易控制台建立的 API Key。

​
第三步：根據任務狀態處理

查詢到不同狀態後，可以按照以下方式處理：
  • 如果狀態是 queued，說明任務仍在排隊，繼續等待並查詢。
  • 如果狀態是 running，說明任務正在生成，繼續等待並查詢。
  • 如果狀態是 succeeded，從 content.video_url 獲取影片並立即下載。
  • 如果狀態是 failed，檢視響應中的 error 資訊。
  • 如果狀態是 expired，檢視任務詳情和呼叫日誌，確認任務過期原因。
不要把 queued 或 running 當成失敗，也不要因為任務尚未完成就重複建立任務。

​
第四步：客戶端超時後先確認任務狀態

如果客戶端沒有收到完整響應，先不要直接重試。 建議按照以下順序排查：
  1. 檢查客戶端響應中是否已經返回 task_id。
  2. 檢查控制台呼叫日誌中是否已經記錄任務。
  3. 如果已經有 task_id，優先查詢原任務。
  4. 如果暫時沒有找到 task_id，不要僅憑網路錯誤判斷任務一定沒有建立。
  5. 如果無法確認任務是否建立，再聯絡客服核查後重試。
這是因為客戶端超時只說明客戶端沒有在預期時間內收到響應，不足以單獨證明服務端沒有建立任務。

​
如何避免重複提交？

以下內容屬於接入側的工程實踐，不是平臺強制規則：
  • 為每次業務請求生成唯一的業務 ID。
  • 儲存業務 ID 與 Seedance task_id 的對應關係。
  • 使用者點選提交後，暫時停用重複提交按鈕。
  • 客戶端超時或程序退出後，優先恢復查詢原任務。
  • 儲存提示詞、模型、時長、比例和參考素材等請求資訊。
  • 只有在確認原任務不存在或已經明確失敗後，再考慮是否重新提交。
  • 輪詢程式應區分處理中狀態和終態，不要把 queued、running 當成失敗。
對於 Agent、指令碼或後臺服務，建議將任務建立和任務查詢拆開處理：
這樣即使本地程式退出，也可以在恢復後繼續查詢原任務，而不是重新建立任務。

​
重複提交後如何核對扣費？

Seedance 2.0 當前文件說明，計費採用：
因此，餘額變化和日誌記錄可能不是一次性完成的。概覽文件還說明，一條影片任務可能對應預扣費和後續結算等多條日誌記錄，最終應以呼叫日誌為準。 另外，因引數錯誤被拒、且沒有建立成功任務的請求，例如 InvalidParameter 型別的 HTTP 400 請求，當前文件說明不計費。 但以下情況不能僅憑一個狀態直接判斷是否扣費：
  • 客戶端 timeout；
  • 網路斷開；
  • failed；
  • expired；
  • 客戶端沒有收到完整響應；
  • 客戶端顯示請求失敗，但服務端可能已經建立任務。
如果已經重複建立了多個任務，請先停止繼續提交，並整理以下資訊：
  • 所有相關的 Seedance task_id；
  • 對應的 request ID；
  • 提交時間；
  • 模型名稱；
  • 主要請求引數；
  • 控制台呼叫日誌；
  • 賬單或扣費記錄截圖。
然後聯絡客服進行人工核查。是否產生費用、是否存在重複扣費，以及後續是否可以進行費用處理，應以實際任務記錄、呼叫日誌、賬單記錄和平臺核查結果為準。
不建議直接根據 failed、expired 或客戶端 timeout 判斷“一定扣費”或“一定不扣費”。

​
常見問題

​
我停止輪詢後，Seedance 任務會自動停止嗎？

不能這樣判斷。 停止輪詢只表示客戶端不再繼續查詢任務狀態。當前公開 API 文件沒有提供取消介面，因此客戶端停止輪詢不等於已經取消服務端任務。 請儲存原來的 task_id，稍後繼續查詢。

​
請求超時後可以直接重試嗎？

不建議直接重試。 應先檢查：
  • 響應中是否包含 task_id；
  • 控制台呼叫日誌中是否已經有任務記錄；
  • 原任務當前是什麼狀態；
  • 是否已經產生對應的計費記錄。
如果原任務已經建立，應先查詢原任務，避免同一業務請求生成多個影片任務。

​
任務顯示 failed 或 expired，一定不會扣費嗎？

不能僅憑任務狀態判斷費用結果。 Seedance 2.0 使用提交預扣、完成後結算的計費方式。請同時檢視呼叫日誌和賬單記錄。如果發現費用記錄異常，請提供任務 ID 和 request ID 聯絡客服核查。

​
引數錯誤導致 HTTP 400 會扣費嗎？

當前文件說明，因引數錯誤被拒、且未建立任務的請求不計費。 例如：
  • 引數格式錯誤；
  • 不支援的解析度；
  • 非法的寬高比；
  • 不支援的影片時長；
  • 模型與引數組合不匹配。
但不要把所有 HTTP 400 都簡單歸類為同一種情況，最終仍應以具體錯誤資訊、任務記錄和呼叫日誌為準。

​
成功後生成的影片地址可以儲存多久？

當前文件說明，成功響應中的 content.video_url 是臨時簽名地址，有效期約為 24 小時。 建議在任務變成 succeeded 後立即下載並轉存，不要把該地址當作永久連結。 當前文件還說明，任務 ID 本身儲存期限為 7 天。為了方便業務追蹤，仍建議在自己的系統中儲存任務記錄。

​
相關文件

​
聯絡我們

如果遇到以下情況，可以聯絡客服協助核查：
  • 任務長時間停留在 queued 或 running；
  • 客戶端超時後無法確認任務是否建立；
  • 重複提交後出現多個任務；
  • 任務狀態與扣費記錄不一致；
  • 成功任務無法獲取或下載影片。
聯絡客服時，請儘量提供：
  • Seedance task_id；
  • request ID；
  • 提交時間；
  • 模型名稱；
  • 主要請求引數；
  • 控制台呼叫日誌；
  • 相關賬單記錄。
客服入口：企業微信客服