Seedance API (2026): Endpoints, Real Prices, Real Latency

Seedance API access finally has published numbers: a per-second price, a measured median latency and a documented task endpoint. Here is how to read them before integrating.

Try the API → Official site

What the model actually generates

Seedance 2.0 is a video generation model from ByteDance, listed with a release date of 15 April 2026. Three input modes are documented. Text to video is the obvious one. Image to video supports first and last frame control, which means you can pin both ends of a shot instead of hoping the model lands somewhere usable. Multimodal reference to video is the interesting one, where reference material guides the output, and the model is described as particularly good at preserving character consistency, visual style and camera movement from that material. That last property is why teams pick it over a general-purpose generator: if you are producing a series of shots featuring the same person in the same world, consistency across renders is worth more than any single clip looking better in isolation.

Two documented ways into the Seedance API

The first-party route runs through ByteDance's ModelArk platform, and its video generation API is asynchronous by design. You create a video generation task, retrieve it to check progress, list your tasks, and cancel or delete one. Before any of that you obtain and configure an API key, install the SDK and set the base URL and authentication, all of which have their own reference pages. The same platform documents image generation, two separate 3D generation families, multimodal embeddings, context caching and managed agents, so this is a full platform rather than a single endpoint. The second route is an aggregator, which wraps the same model behind a familiar interface and publishes operational statistics the vendor does not. There are also community wrapper repositories on GitHub, which are convenient and are maintained by whoever happens to feel like it.

How the meter actually works

Two units appear, and mixing them up will wreck a cost estimate. The aggregator listing shows a headline of from $0.06726 per second, while the single upstream provider behind it is quoted at $7.00 per million tokens and $0.1512 per second for video, with the same figures whether or not audio is included. Tokens for a video are defined by a published formula: output height multiplied by output width multiplied by duration multiplied by 24, all divided by 1024. Work that through for your actual resolution before budgeting, because the token count scales with pixel area, not just with length. A short clip at high resolution can cost more than a longer one at a modest size, which is the opposite of the intuition most people bring from text models.

Latency and availability decide the architecture

The operational numbers matter more than the price for anything user-facing. Median end-to-end latency was measured at 123.8 seconds, so a render takes about two minutes and no amount of engineering on your side changes that. Over a recent three-day window, uptime was reported at 100 percent, meaning requests reached a provider, while availability sat at 93.84 percent, meaning inference actually came back. Those are different measurements and the second one is the one that hurts: roughly one request in sixteen returned an error or an empty response. The aggregator notes that this model is served by exactly one provider, so requests are forwarded directly with no routing choice and no healthy alternative to fall back on. Build retries, idempotent job records and a user-facing waiting state accordingly.

Do not wire your product to one model

Every generation model in this category has now been superseded at least once, usually within months of somebody building a product on it. The cost of that is rarely the model itself; it is the queue handling, the polling loop, the error taxonomy and the billing reconciliation that all got written against one vendor's shape. Keeping that layer generic is the difference between swapping a model in an afternoon and rewriting a service. Synexa exists for that job: one REST endpoint and a Python SDK covering FLUX along with video and audio models, billed per run, so the integration work survives the next release cycle. Whether you route through it or build your own abstraction, the principle holds. Keep the vendor-specific part small enough to throw away.

The numbers worth writing down

Direct integration next to Synexa

Integrating without regret

1. Do the token arithmetic first
   Multiply height by width by duration by 24, then divide by 1024. Run that for your real output settings before anyone signs off on a budget built from a per-second headline.
2. Design for two minutes
   With a median render near 124 seconds, the job has to be asynchronous end to end: a queued record, a status endpoint and a screen that tells the user what is happening.
3. Write the retry path early
   Availability near 94 percent over three days means failures are routine, not exceptional. Make job creation idempotent so a retry never bills you twice for the same clip.
4. Keep the vendor code thin
   Put the task creation, polling and error mapping behind one interface. When the next model ships, you want to change an adapter rather than audit your whole service.

FAQ