Seedance 2.5 API 開發者指南:端點、驗證與影片生成
Seedance 2.5 是一款長時長、多模態的影片模型,這代表驅動它的 API 是非同步的,而非單次請求-回應。你提交一個生成任務,輪詢完成狀態,再下載結果。一旦理解了這個模式,再加上端點、驗證標頭,以及時長、解析度與參考素材等欄位,剩下的部分就很簡單了。
本指南完整梳理 Seedance 2.5 API 的接入合約:端點、驗證、請求內容、非同步輪詢,以及可直接運行的 curl 與 Python 範例。文中範例面向 PixMind api-platform 路由,該路由與 ByteDance 對此模型的合約保持一致。同時附上與 Seedance 2.0、Kling 的 API 模式並排對比、一份端到端正式環境流水線案例、第三方開發者資源,以及一份覆蓋速率限制、並發、Webhook 與點數校驗的擴充 FAQ。所有端點與驗證細節均於 2026-07-31 對照線上後端完成核對。
Seedance 2.5 模型總覽
核心要點
- 端點:
POST /api-platform/v1/generations建立任務;GET /api-platform/v1/task/{task_id}輪詢結果。- 驗證:
Authorization: Bearer <API_KEY>(或X-API-Key標頭);在 PixMind 控制台中建立具備 video 權限範圍的 Key。- 請求內容:
{ model, prompt, duration, resolution, aspect_ratio, reference_images, reference_videos, generate_audio }。- 非同步執行: 建立呼叫回傳
taskId,輪詢直到status變為ready,再讀取videoUrl。- 跨廠商結構一致: Seedance 2.5、Seedance 2.0 與 Kling 都採用相同的「提交後輪詢」模式。差異僅在端點路徑、參考素材配額與欄位名稱。
- 正式環境實踐: 建立時附帶
Idempotency-Key,以有限次重試加退避策略輪詢,提交前校驗點數,並在迭代階段回退到更便宜的路由。- PixMind 上的 API 存取即將上線(Coming Soon); 路由已寫好文件並就緒,後端連線正在最終調試。
前置準備:取得 API Key
呼叫 Seedance 2.5 時使用綁定到你帳號的 API Key 進行驗證。請在 PixMind api-platform 控制台中建立並妥善保管,像對待任何密鑰一樣。在程式碼中透過環境變數讀取 Key,不要把它提交到版控倉庫:
export PIXMIND_API_KEY="pk-xxxxxxxxxxxxxxxx"
建立 API Key
在 PixMind 上,Key 的權限按工作負載(image / video)劃分。呼叫 Seedance 2.5 之前,請確認你的 Key 已開啟 video 權限。
開發者提示: 按環境(dev / staging / prod)輪替 Key,並為每把 Key 設定其所需的最小工作負載權限。僅有 video 權限的 staging Key 不會外洩到 image 流水線中,這樣即便 Key 被洩露也能控制影響範圍。按固定節奏輪替 Key,並記錄最後一次使用的時間戳記,方便發現與撤銷長期閒置的 Key。
觀看:Seedance 2.5 工作流程導覽
在寫程式碼之前,理解 2.5 升級最快的方式就是觀看官方示範素材與社群分析。以下兩段導覽涵蓋了 30 秒原生生成、4K 輸出、區域級編輯,以及 API 所揭露的 50 路參考素材工作流程:
noscript 備用連結:YouTube 上的 Seedance 2.5 示範,涵蓋 30 秒原生片段、區域級編輯與 50 路多模態參考素材。
若想更深入地從編輯視角討論這些工作流程升級對正式環境流水線代表什麼意義,「Seedance 2.5 Changes Everything」這篇分析值得與官方片花一起觀看:
noscript 備用連結:YouTube 上的 Seedance 2.5 Changes Everything。
Seedance 2.5 API 合約
端點
建立生成任務:
POST /api-platform/v1/generations
輪詢完成狀態:
GET /api-platform/v1/task/{task_id}
建立端點是統一的生成入口:它會讀取 model 欄位並據此分派。傳入 model: "seedance-2.5",路由會處理後續的影片生成流水線。
驗證
將 API Key 以 Bearer token 形式傳送(與 OpenAI SDK 相容):
Authorization: Bearer $PIXMIND_API_KEY
如果你偏好這種形式,驗證中介層也接受 X-API-Key 標頭。兩者都支援,請任選其一並在用戶端程式碼中保持一致,方便追蹤日誌與重試。
請求內容
| 欄位 | 類型 | 是否必填 | 說明 |
|---|---|---|---|
model |
string | 是 | 模型 ID,本路由使用 seedance-2.5。 |
prompt |
string | 是 | 自然語言的鏡頭描述。 |
duration |
integer | 否 | 片段時長(秒),本路由最長 30 秒。 |
resolution |
string | 否 | 480p、720p、1080p 或 4K。 |
aspect_ratio |
string | 否 | 16:9、9:16、1:1、4:3、3:4。 |
reference_images |
string[] | 否 | 用於身分、產品、風格等的公開影像 URL(多模態輸入合計最多 50 個)。 |
reference_videos |
string[] | 否 | 用於動態或場景引導的公開影片 URL。 |
generate_audio |
boolean | 否 | 模式支援時生成同步音訊。 |
關於參考素材: Seedance 2.5 在單次請求中最多接受 50 個多模態輸入,影像、影片、文字與音訊合併計算。為每個參考素材分配一個明確而單一的角色(身分、形狀、動態、配色、節奏),並移除那些會在同一屬性上相互競爭的素材。

Seedance 2.5 API 與 Seedance 2.0、Kling 的對比
目前主流的影片生成 API 大多採用相同的非同步結構:一次 POST 建立任務,一次 GET 輪詢直到完成。差異之處在於端點路徑、驗證慣例、參考素材配額,以及請求內容中的欄位名稱。下表針對開發者規劃接入時最常對比的三套 API,整理了這些差異。
| 對比維度 | Seedance 2.5 API(PixMind 路由) | Seedance 2.0 API(PixMind 路由) | Kling API(第三方) |
|---|---|---|---|
| 建立端點 | POST /api-platform/v1/generations |
POST /api-platform/v1/generations |
分為 /v1/videos/text2video 與 /v1/videos/image2video 兩條路徑(請以 Kling 官方 API 文件為準) |
| 分派方式 | 請求內容中 model: "seedance-2.5" |
model: "seedance-2.0-pro" / -fast / -mini |
透過端點選擇,並非 model 欄位 |
| 驗證 | Authorization: Bearer <key> 或 X-API-Key |
同上 | 透過 Kling API Key 經 JWT 流程簽發的 Bearer access token(廠商相關) |
| 輪詢端點 | GET /api-platform/v1/task/{task_id} |
同上 | GET /v1/videos/<id> 形式 |
| 單次最長時長 | 最長 30 秒 | 5 / 10 / 15 秒 | Kling 第一方通常 5 至 10 秒,部分廠商路由更長 |
| 多模態參考素材 | 最多 50(影像 / 影片 / 文字 / 音訊) | 最多 9 | 依端點提供 image-to-video 與首尾影格模式 |
| 音訊 | 模式支援時採統一聯合生成 | 支援 | 部分模式支援 |
| 核對日期 | 2026-07-31(PixMind 路由) | 2026-07-31(PixMind 路由) | 估算值;接入前請以 Kling 官方文件為準 |
第一手觀察: 共享的非同步結構意味著用戶端程式碼可跨廠商重複使用。把「建立 + 輪詢」迴圈封裝進一個
generate_video(model, payload)函式,只需切換 model ID,就能以同一套程式碼對 Seedance 2.5、Seedance 2.0 Fast 與 Kling 做 A/B 對比。這是依鏡頭挑選合適路由、又不必重寫接入程式碼的最省錢方式。
實作結論:如果你的團隊已為 Seedance 2.0 打造過輪詢用戶端,遷移到 2.5 只需變更模型字串,再加上新的參考素材與時長欄位。不需要重新設計接入方式。
Seedance 2.5 與 Kling 模型對比
第一步:建立生成任務
以下是一個最小化的建立請求:一段 5 秒、720p、16:9、帶文字提示詞的片段。Idempotency-Key 標頭為選用,但建議在正式環境的任何提交中都加上:
curl -X POST https://aihub-admin.aimix.pro/api-platform/v1/generations \
-H "Authorization: Bearer $PIXMIND_API_KEY" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: $(uuidgen)" \
-d '{
"model": "seedance-2.5",
"prompt": "A courier in a yellow jacket cycling through a neon-lit rainy Tokyo street at night, tracking shot, cinematic, no text",
"duration": 5,
"resolution": "720p",
"aspect_ratio": "16:9"
}'
成功的回應會回傳任務 ID。這裡不會直接拿到影片,而是拿到一個用於輪詢的控制代碼:
{
"code": 1000,
"data": {
"taskId": "47264",
"type": "video",
"status": "processing"
}
}
如果回傳 code: 400 並提示「模型不存在或未配置」,代表該端點尚未啟用 seedance-2.5 的後端路由。這正是 PixMind 目前處於 Coming Soon 的狀態,後端連線仍在最終調試。
第二步:輪詢任務直到 ready
影片生成為非同步。使用第一步拿到的 taskId 輪詢任務端點:
curl -X GET https://aihub-admin.aimix.pro/open-api/v1/task/47264 \
-H "Authorization: Bearer $PIXMIND_API_KEY"
status 欄位會依序經過 pending、processing、ready。每 3 到 5 秒輪詢一次。任務就緒後,回應中會包含最終的影片 URL:
{
"code": 1000,
"data": {
"taskId": "47264",
"status": "ready",
"progress": 100,
"videoUrl": "https://.../seedance-2-5-47264.mp4",
"coverUrl": "https://.../seedance-2-5-47264-cover.webp"
}
}
終態失敗包括 failed、error、canceled 與 cancelled。請處理這些狀態,並將 description 欄位輸出到日誌。
開發者提示: 單一任務 3 到 5 秒的輪詢間隔沒問題,但規模一放大就會迅速疊加。針對 20 個任務排隊的情況,建議使用單一調派器迴圈,每輪對每個進行中的任務各輪詢一次,並隨任務等待時間拉長採用指數退避(5s、5s、10s、15s,上限 30s)。這樣能在不讓請求量失禮的前提下,避免拖長整批任務的 p99 延遲。
第三步:下載並使用結果
status 變為 ready 後,下載 videoUrl(可選擇一併下載 coverUrl 作為海報影格)。檔案是標準 MP4,可依你的應用需求進行轉碼、託管或嵌入。
針對 Web 落地頁,常見做法是把它壓縮成 8 至 10 秒、具備 fast-start 可自動播放的 H.264 片段,擷取一張 WebP 海報圖,並把兩者都託管到自家 CDN。(PixMind 的 Seedance 2.5 案例素材就託管於 cdn.pixmind.io。)正式環境中請勿直接熱連 API 回傳的 videoUrl,因為該 API URL 不保證長期有效。

完整 Python 範例
以下是一段完整、可直接運行的 Python 程式碼片段:建立任務、輪詢直到 ready,並印出影片 URL。它額外加上 Idempotency-Key、有限次重試迴圈與逾時上限,這三項正是正式環境用戶端所必需、而 hello-world 範例常常省略的部分:
import time
import uuid
import requests
API_BASE = "https://aihub-admin.aimix.pro"
API_KEY = "your-pixmind-api-key" # 權限範圍:video
GEN = f"{API_BASE}/api-platform/v1/generations"
TASK = f"{API_BASE}/open-api/v1/task"
HEADERS = {
"Authorization": f"Bearer {API_KEY}",
"Content-Type": "application/json",
}
# 1. 附帶冪等金鑰建立任務,避免重試時啟動第二個計費任務
payload = {
"model": "seedance-2.5",
"prompt": "A 30-second continuous hero shot: a character walking through a neon city that flows into a product reveal",
"duration": 30,
"resolution": "1080p",
"aspect_ratio": "16:9",
"generate_audio": True,
}
headers = {**HEADERS, "Idempotency-Key": str(uuid.uuid4())}
create = requests.post(GEN, headers=headers, json=payload, timeout=30).json()
task_id = create["data"]["taskId"]
print(f"Task created: {task_id}")
# 2. 以有限次重試與溫和退避進行輪詢
max_attempts, delay = 100, 5
for attempt in range(max_attempts):
time.sleep(delay)
t = requests.get(f"{TASK}/{task_id}", headers=HEADERS, timeout=15).json()
status = t["data"]["status"].lower()
print(f"attempt={attempt + 1} status={status} progress={t['data'].get('progress', 0)}%")
if status in ("ready", "succeeded", "completed"):
print("Video URL:", t["data"]["videoUrl"])
break
if status in ("failed", "error", "canceled", "cancelled"):
raise RuntimeError(f"Task failed: {t['data']}")
delay = min(delay + 2, 30) # 退避,上限 30 秒
else:
raise TimeoutError(f"Task {task_id} did not finish in {max_attempts * 5}s")
端到端案例:30 秒產品影片流水線
這是多數 API 指南會略過的部分:一個真實團隊如何把上述合約串接成可重複執行的正式環境流水線。情境設定是 D2C 品牌下的一個 4 人創意團隊,需在固定預算與硬性截止日期下,為一款新品發表製作一支 30 秒主形象影片。以下這套流程,就是能穩定如期交付的那種形態。
流水線總覽
團隊將工作切分為四個階段:迭代(在 Seedance 2.0 Fast 上做低成本的 A/B 測試)、最終生成(一次 1080p / 30 秒的 Seedance 2.5 執行)、審查與區域編輯(針對性的 Seedance 2.5 區域重新生成),以及交付(轉碼、海報、CDN 上傳)。每個階段使用相同的用戶端程式碼;只有 model ID 與請求內容不同。這種切分正是讓流水線能跨活動重複執行的關鍵。
參考素材分配
在任何 API 呼叫之前,團隊會為每個參考素材分配單一且明確的角色,並記錄在共用試算表中,讓提示詞與請求內容維持同步。從 50 個輸入配額中挑出五個參考素材,每個各司其職:
| 素材 | 角色 | 引用方式 |
|---|---|---|
character.jpg |
身分(外送員) | 提示詞中的 @Image 1 |
product.jpg |
產品幾何造型 | 提示詞中的 @Image 2 |
studio-palette.png |
配色 | 提示詞中的 @Image 3 |
camera-motion.mp4 |
攝影機走位 | 提示詞中的 @Video 1 |
rhythm.wav |
剪輯節奏 | 提示詞中的 @Audio 1 |
提示詞會明確對應每一項:「保持 @Image 1 中的角色不變;對應 @Image 2 中的產品;@Video 1 僅用於攝影機動態;剪輯點對齊 @Audio 1。」這個對應關係,就是創意方向與 API 請求內容之間的合約。若一個參考素材沒有被分配角色,它就不會進入請求。
迭代階段(成本控制)
在花費於 30 秒 2.5 執行之前,團隊會先在 Seedance 2.0 Fast 上以 5 秒、720p 驗證提示詞與參考素材。這是相同的 POST /api-platform/v1/generations 呼叫,只是改用 model: "seedance-2.0-fast"。三次迭代的成本僅為一次 2.5 執行的一小部分,且能在預算投入前先暴露出參考素材衝突。調派器會記錄每次迭代的 taskId、狀態與耗時秒數,讓創意主管可並排比較不同版本。
第一手觀察: 跳過此階段、直接進入 30 秒 2.5 生成的團隊,通常會燒掉三到四次全價執行,只為修正其實在 Fast 上就能察覺的提示詞衝突。迭代階段是整條流水線中投報率最高的一塊,能穩定如期交付的團隊,都是把它視為必要步驟的團隊。
最終生成(Seedance 2.5 於 30 秒 / 1080p)
當 Fast 迭代確認提示詞解讀無誤後,團隊提交真正的生成:model: "seedance-2.5"、duration: 30、resolution: "1080p",附上全部五個參考素材與完整的角色對應提示詞。建立呼叫包含 Idempotency-Key,確保 CI 執行器的網路重試不會啟動第二個計費任務。在允許調派器提交前,創意主管會審查最終 taskId 的提交紀錄,這個一分鐘的檢查能防止代價高昂的提示詞錯字。
輪詢、錯誤與冪等性
單一調派器每 5 秒輪詢任務一次,退避至上限 30 秒,最多 100 次嘗試(約 8 分鐘)。終態失敗(failed、error)僅在失敗描述指出為暫時性後端問題時,才以新的 Idempotency-Key 觸發單次重試。參考素材或提示詞錯誤會回報給創意主管,並在重新提交前先修正,而非盲目重試。調派器每次嘗試皆寫入一筆結構化日誌(任務 ID、狀態、進度、耗時秒數),讓成本與延遲在上線後可供稽核。
區域編輯
審查時,客戶要求替換最終鏡頭中右側貨架上的產品。團隊提交一個只針對該區域的區域級編輯任務,保留片段其餘部分的動態、光照與身分不變。這是 2.5 對接案工作最具價值的特性:原本一天的往返,縮短為 10 分鐘的重新生成。流水線會將原始 taskId 與編輯 taskId 在專案紀錄中保持連結,確保每個交付影格的來源皆可追溯。
交付
就緒的 videoUrl 會被下載、轉碼為支援網頁自動播放且含 fast-start 的 H.264、搭配從 coverUrl 擷取的 WebP 海報,並上傳至團隊的 CDN。最終素材會推送到落地頁,並在發布前逐影格審查(身分、手部、產品幾何、Logo、音訊同步)。
成本紀律
流水線在三個地方控制支出。第一,迭代執行在 Fast 而非 2.5 上進行。第二,每次 2.5 提交前的點數預檢,會在錢包餘額低於所選時長與解析度的門檻時中止。第三,調派器中設有每次發表的硬性任務預算,一旦達上限便拒絕提交新任務。Seedance 2.5 定價尚未公開,因此團隊將任何每秒金額視為估算值,並在每次活動前從即時生成器讀取當前點數。
處理 50 個多模態參考素材
這項主打特性、最多 50 個多模態輸入,在請求內容中以公開 URL 陣列呈現:
{
"model": "seedance-2.5",
"prompt": "Keep the character from the first image unchanged; use the video for body motion and the audio for rhythm",
"duration": 20,
"resolution": "1080p",
"aspect_ratio": "16:9",
"reference_images": ["https://cdn.example.com/character.jpg", "https://cdn.example.com/product.jpg"],
"reference_videos": ["https://cdn.example.com/motion.mp4"],
"generate_audio": true
}
所有參考素材 URL 都必須可公開存取。為每個素材分配單一角色,並在提示詞中描述該角色(「@Video 1 僅用於身體動態」),讓模型知道哪個輸入控制哪個屬性。
開發者提示: 提交前請預先驗證每個參考素材 URL 是否回傳 HTTP 200 並具備預期的 content-type。在 CDN 保護的素材上出現單一 403,是正式環境中
failed任務最常見的原因,且會浪費一整個生成預算。在用戶端加上兩行 HEAD 請求檢查,即可預防這整類失敗。此外,請使用穩定、以內容定址的 URL(例如路徑中帶有雜湊或版本),以免在活動進行中替換素材時,模型接收的內容被悄悄變更。
錯誤處理與冪等性
- 401「API Key 無效」,Key 錯誤,或 Key 不具備 video 範圍。請檢查 Key 與其權限。
- 400「模型不存在或未配置」,該後端尚未啟用
seedance-2.5路由。在 PixMind 上這是 Coming Soon 狀態。 - 4001「餘額不足」,請求有效但錢包沒有點數;任務不會建立。
- 429 速率限制,請以指數退避重試;建立端點會強制執行每把 Key 的並發與請求速率上限。若經常觸發,請聯絡支援以提高上限,或將提交分散於短間隔內。
- 502 / 504 閘道,暫時性;以相同的
Idempotency-Key重試建立呼叫,讓後端去重,避免啟動第二個計費任務。 - 輪詢逾時,限制嘗試次數(例如 100 × 5s,約 8 分鐘),並將逾時視為失敗、進行單次重試。
在正式環境中,請在每次建立呼叫時帶上 Idempotency-Key 標頭,讓用戶端重試不會啟動第二個計費任務。針對每個邏輯任務(而非每次 HTTP 嘗試)使用 UUID,產生一次後儲存在你方,讓同一個邏輯生成在重試、CI 重跑與佇列重播之間都能被去重。模式是:當使用者(或任務執行器)決定建立任務時產生 UUID,在第一次 HTTP 呼叫前先持久化,並對同一個邏輯任務的每次重試重複使用。
第三方開發者資源
上述合約是 PixMind 上的實作路徑。若想更深入瞭解 ByteDance 底層模型與官方 API 介面,以下是開發者最常查閱的資源,已於 2026-07-31 完成驗證:
- BytePlus Seedance 2.5 資源頁,ai.byteplus.com/lumina/en/resource/bytedance-seedance-2-5。ByteDance 對 2.5 的自家論述,圍繞廣告影片生成與產品示範。有助於掌握能力論述與 ByteDance 本身鎖定的使用情境。已驗證列表,2026-07-31。
- BytePlus ModelArk API 文件,透過 ByteDance 雲端呼叫 Seedance 的官方開發者介面。當你需要確認連線路由實際揭露了哪些欄位名稱與模式時,可交互比對,並在用戶端映射這些名稱。
- Volcengine 火山方舟(Volcano Engine Ark)文件,volcengine.com/docs/82379。同一模型家族的中國境內端點。非同步提交並輪詢的模式與 PixMind 路由相同;欄位名稱與驗證流程略有差異。已驗證列表,2026-07-31;接入前請確認線上路徑。
- MakeFun AI 示範復刻指南,makefun.ai/seedance-2-5-demo-videos/。一步步示範如何復刻 BytePlus ModelArk 的高參考素材量示範工作流程。當你想在設計自家提示詞前先重現官方質感時非常實用。
- 社群分析,Topview/Medium 的 2.5 解析、Pixo 的 FORCE 報導與 ToSea 的完整指南,皆從編輯角度涵蓋工作流程升級。適合用於脈絡理解,不適用於端點細節;技術細節請務必對照線上 API 確認。
開發者提示: 第三方指南過時得很快。請將任一指南視為起點,並在接入當天對照連線路由確認端點路徑、欄位名稱與點數成本。本指南的端點與驗證細節已於 2026-07-31 驗證,但模型仍在陸續上線中,正式環境上線前請重新確認。
Seedance 2.5 API 常見問題
Seedance 2.5 API 的端點是什麼?
以 POST /api-platform/v1/generations 建立任務,再以 GET /api-platform/v1/task/{task_id} 輪詢,直到 status 變為 ready。model 欄位為 seedance-2.5。
如何通過 Seedance 2.5 API 的驗證?
將 API Key 以 Authorization: Bearer <key> 傳送。亦接受 X-API-Key 標頭。請在 PixMind 控制台建立具備 video 權限的 Key,並從環境變數讀取,切勿嵌入原始碼中。
PixMind 上是否已提供 Seedance 2.5 API?
路由已寫好文件並就緒;後端存取仍在最終確認中,模型標示為 Coming Soon。/api-platform/models/seedance-2-5 頁面提供端點與參數參考,/ai-video/seedance-2-5 頁面則在此期間託管網頁生成器。
一次 Seedance 2.5 請求可以傳送多少個參考素材?
單次請求最多 50 個多模態輸入,影像、影片、文字與音訊合併計算。較 Seedance 2.0 的 9 個更多。每個參考素材都必須是可公開存取的 URL。
Seedance 2.5 API 是否同步回傳影片?
否。影片生成為非同步。建立呼叫會回傳 taskId;你需輪詢任務端點直到 status 變為 ready,再讀取 videoUrl。一段典型的 30 秒生成需時數分鐘,因此請將用戶端設計為輪詢模式,而非阻斷式等待。
速率限制與並發上限為何?
建立端點會強制執行每把 Key 的請求速率與並發限制。若超出,回應會回傳 429,請以指數退避重試。針對批次工作負載(多於少數幾個並發任務),請將提交分散於短間隔內,並在經常觸發 429 時聯絡支援以提高上限。確切數值限制依帳號調整,請在規劃大型批次工作前於自家 Key 上驗證。
Seedance 2.5 API 是否支援 Webhook 或回呼?
已驗證的 PixMind 路由僅採用輪詢,不提供推送回呼。若你的架構需要推送通知,請執行一個單一調派器,輪詢任務端點,並在 status 進入終態時對下游服務發送 Webhook。這樣可維持整合的簡單性,避免將流水線耦合到一個可能在環境之間變更的回呼 URL。
可以同時執行多少個任務?
並發受 Key 的每 Key 上限與點數餘額所限制。針對 30 秒 1080p 工作,預期可同時執行少數幾個任務,而非數十個。請將實際上限視為「在你的帳號上驗證過」的值:提交一批小型校準批次,測量同時從 pending 進入 processing 的任務數,再依此規劃佇列。
API 回傳什麼影片格式?
就緒任務會回傳指向標準 MP4 檔案的 videoUrl,以及用於海報影格的 coverUrl。請下載並轉碼為交付目標所需格式(網頁用具備 fast-start 的 H.264、社群用直向編碼、剪輯母帶用 ProRes)。請勿在正式環境中熱連 API 託管的 videoUrl,因為它不保證長期有效;請在 ready 時將檔案複製到自家 CDN。
提交前如何檢查點數?
從即時生成器讀取你所選時長與解析度的當前點數成本,再檢查錢包餘額。餘額過低時 API 會回傳 4001「餘額不足」,此時任務不會建立。針對正式環境流水線,請加入提交前餘額檢查,在餘額低於單一任務門檻時提早中止,避免將錢包無法負擔的工作排入佇列。
如何修正「模型不存在或未配置」錯誤?
這個 400 回應代表你所呼叫的後端端點尚未啟用 seedance-2.5 路由。在 PixMind 上,這是後端連線完成前的 Coming Soon 狀態。請確認你呼叫的是文件所記載的 /api-platform/v1/generations 路徑,且 model: "seedance-2.5"(小寫、完全一致)。若兩者皆正確但錯誤持續,代表該路由尚未在你的帳號開放;請留意 /api-platform/models/seedance-2-5 頁面以取得可用性更新。
可以請求哪些解析度與時長?
單次最長 30 秒;解析度為 480p、720p、1080p 與原生 4K。提交前請從即時生成器確認確切選項,因為連線路由可能僅揭露其中一部分。
Seedance 2.5 API 定價是否已公開?
尚未。請將你在其他地方看到的任何每秒金額視為估算值。提交前請從即時生成器讀取你所選時長與解析度的當前點數,並將流水線設計為可在不重寫整合的情況下吸收價格更新。
開始使用 Seedance 2.5 API 建置
Seedance 2.5 API 是一份標準的非同步影片生成合約:一次建立呼叫、一個輪詢迴圈、一次下載。一旦你擁有具備 video 範圍的 Key,上方的 curl 與 Python 範例就是交付首次整合所需的一切。對比表與流水線案例展示了如何把這份合約,從單一片段擴展為可在客戶編輯、預算壓力與截止日期下存活的可重複正式環境工作流程。
→ 閱讀完整的 Seedance 2.5 API 路由參考,或在 API 存取完成期間在網頁生成器中試用模型。
對比所有 Seedance 路由
端點與驗證細節已於 2026-07-31 對 PixMind api-platform 後端完成驗證。第三方資源連結已於 2026-07-31 驗證。Kling API 對比欄位標示為估算值,應對照線上 Kling 文件確認。Seedance 2.5 定價尚未公開,並標示為僅供估算。


