2026-11-01 · VideoFreeTier

Seedance 2.5 API: Every Tutorial That Ranks Sells a Different Endpoint

The official Seedance 2.5 API is one host, one model string and one auth header: POST https://ark.ap-southeast.bytepluses.com/api/v3/contents/generations/tasks, an Authorization: Bearer header, and the model dreamina-seedance-2-5-260628. The tutorials that rank for "seedance 2.5 api" do not use any of the three. They hand you a key from Atlas Cloud, Muapi or fal, where the host, the header name and the model identifier are all different, and that key is checked by the platform that issued it. That is the shape of the complaints underneath those videos — "Which API i have to buy" and "Problem=Not authenticated" — and it is not a fault in the model.

Everything below was read on 1 November 2026 as a guest: the vendor's tutorial and API reference pages, the error-code table, and the public pages of three platforms that resell the model. No BytePlus account was created, no key was issued and no request was sent, so nothing here is a tested call. The reseller side is what those pages say about themselves, marked as such wherever it appears. Prices are not the subject of this page; there is a separate one on the token meter.

The vendor's page prints the same request four times

The tutorial page for this model gives the same call in cURL, Python, Java and Go, and the four agree on every string that matters. The Python sample sets base_url='https://ark.ap-southeast.bytepluses.com/api/v3'; the Java sample passes the identical base URL to .baseUrl(); the Go sample hands it to WithBaseUrl(). None of them is a placeholder.

The model table is worth reading as a table rather than as a paragraph, because it fixes four distinct strings for four distinct models: dreamina-seedance-2-5-260628, dreamina-seedance-2-0-260128, dreamina-seedance-2-0-fast-260128 and dreamina-seedance-2-0-mini-260615. There is no seedance-2-5 in it. A slug that reads like the product name is a platform's identifier, not the vendor's, and a request carrying it is a request to whoever owns that slug.

One step in Getting started sits between the key and the call, and it is the step the tutorials skip: "Activate the model: Make sure you have purchased a resource pack. Otherwise, you cannot activate Seedance 2.5." A key on its own does not unlock the model. What that pack costs, and whether any free tokens apply, is a separate question answered on the page about the free-token table.

The call is asynchronous in a way that matters for identification. Creating a task returns an identifier; the video arrives only after a second request to …/api/v3/contents/generations/tasks/{id}, whose response carries status and, on success, content.video_url. The docs say it plainly: "The video generation task creation is an asynchronous API. After obtaining the ID, you need to query the status of the video generation task."

The ten-second check that says which API you are calling

Four questions settle it, and all four can be answered from the code you copied before you run anything.

The first is the host. If the request does not go to ark.ap-southeast.bytepluses.com, it is not going to the vendor, whatever the surrounding page calls the model.

The second is the header name. The vendor wants Authorization, with the word Bearer and a space before the key. Its error table has a dedicated code for getting this wrong — MissingHeader, 401, "Authorization header is required for this request", with the note that the header "must exist, be non-empty, and use the Bearer <token> format". A key sent under some other header name fails there, before the model is reached.

The third is the model string, compared character for character against dreamina-seedance-2-5-260628. A near miss is not a near miss; it is a different model or no model.

The fourth is the identifier that comes back. On the vendor's API it looks like cgt-…. If the create call returns something else, or returns a video directly instead of a task, you are on a synchronous wrapper around the model, not on the model's own API.

None of these four checks requires a key, which is the point: the confusion in the tutorials is visible before anyone spends anything.

What the tutorials hand you instead

The three platforms named in the ranking videos each publish their own way in, and each differs from the vendor on the header, the host, or both.

Atlas Cloud is the most instructive of the three, because of a sentence in its own page furniture. The model page carries the title "Dreamina Seedance 2.5 Now Live" and, beneath it, "Official Endpoints on Atlas Cloud". Read the rest of that page and "official" turns out to mean official to Atlas Cloud: its documentation distinguishes the inference host api.atlascloud.ai from a separate console.atlascloud.ai used for asset uploads, and says both take the same Authorization: Bearer {key} header. The vendor's host does not appear in that description at all.

The parameter names diverge as well. Atlas's own text refers to image fields called reference_images, image and last_image. The vendor's schema has no such fields: an image goes in as a content entry of type image_url carrying a role of first_frame, last_frame or reference_image, and audio and video go in as reference_audio and reference_video. Five fixed strings, one of them required in each entry. A payload written for the first schema is not a payload for the second, and no amount of key-swapping converts it.

Muapi is a different case again, and the cleaner illustration of why a key does not travel. The platform describes itself as giving developers "a single x-api-key HTTP API for 100+ AI image, video, audio, lipsync, and 3D models". One key, one header, many models — that is the product. It is also the reason a key from there has no meaning on a host that authenticates with Authorization: Bearer.

fal's divergence is in the identifier: it lists the model as fal-ai/bytedance/seedance/v2.5/pro, a path built from its own namespace plus the vendor's company name. Nothing about that string is wrong on fal. It is simply not the string the vendor's API matches on.

Four values, three of them described

The parameter that decides which kind of omni-reference task you are asking for is omni_reference_task_type, and on 1 November 2026 the vendor's own documentation describes it inconsistently.

The API reference lists four supported values and defines each: auto, the default, where "the model determines the task type from the input assets and prompt"; reference, a reference-to-video task with "no special constraints" on ratio or duration; edit, which requires at least one reference_video of 4–30 seconds, ratio of adaptive and duration of -1; and extend, which requires a reference_video and an adaptive ratio.

The tutorial's configuration section describes three. It gives a recipe for the case where you do not want to name a subtask — set the parameter to auto — then recipes for edit and for extend. reference is never mentioned in that section. And yet the tutorial's own cURL sample for a reference task sends "omni_reference_task_type": "reference", as do its Python, Java and Go samples on the same tab. The page uses a value its prose does not document.

That is not a typo in one sample. It is the difference between two validation timings, and the timing is the part worth knowing:

So the value that the tutorial's prose omits is the one that behaves most like the plain reference task people think they are asking for. If you follow the prose and set auto, a mismatch between your prompt and the parameters surfaces later, as a failed task rather than a rejected request — which is exactly the failure mode a tutorial reader is least equipped to debug.

The two error codes that tell you the model, not the platform, is unhappy

The vendor's error table names two codes specific to this model's task typing, and both are 400 BadRequest.

InvalidParameter.TaskTypeConstraint reads: "The parameter(s) {Parameter} [and {Parameter}...] specified in the request is/are not valid. {task type description}. Issues: [0] {detail}. [1] {detail}." The remedy printed beside it is to update the parameters according to the issue details.

InvalidParameter.TaskTypeMismatch reads: "The parameter {Parameter} specified in the request is not valid: You requested the {requested task type} task type, but Seedance classified your task as {identified task type} based on your prompt and input." The remedy is to revise the prompt and input assets.

The second one is the interesting one, because it is the model overruling you. Setting omni_reference_task_type to edit gets your parameters validated early, but the model still classifies the task from the prompt when it runs; if the classification disagrees with the value you sent, you get a TaskTypeMismatch on a task that was accepted. The parameter is a hint that moves validation earlier, not a switch that fixes the task type. The docs say as much in a note directly above the code.

Neither of these is an authentication error. They are the errors you see once the key, the host and the model string are all right — which is why they are useful as a diagnostic: if you are getting either of them, you are on the official API and the remaining problem is the request.

Why the comments ask which API to buy

The question under the most-watched tutorial is not about prompting:

"Which API i have to buy for Open Generative AI if i want to generate video with Seedance ? Because to the App i can choose Seedance Lite and others but Seedance 2.5 not available." — @@Tradingalgorobot, YouTube comment, collected 29 October 2026

And a second, shorter one from a different video: "Problem=Not authenticated" — @@Haniff1988, same collection. Both are reports from users, recorded as reports, not as measurements of anything.

The mechanism that produces them is documented on both sides, and the two documents meet neatly. A platform that authenticates with x-api-key issues keys it recognises. The vendor's host authenticates with Authorization: Bearer, and its error table has a 401 MissingHeader for requests that arrive without that header in that form, and a 401 AuthenticationError — "The API key or AK/SK in the request is missing or invalid" — for keys it cannot verify. A key from a reseller, sent to the vendor's host, is a key the vendor has never issued. This site did not run that experiment, so what follows is inference from the two documents rather than a measured result: the request should fail at authentication, before the model is involved, and the user sees a credential error on a page that told them the model was free to try.

There is an older version of the same confusion in a Hacker News comment from 2 August 2026: "Byteplus API is the official way to access it as an API but I am not sure if they serve 2.5 yet". That was a reasonable question at the time. The tutorial page now opens with the model's own API documentation, and the comment was never updated — a small example of how a stale answer outlives the question it answered.

What the ranking looked like on 1 November 2026

Sixteen results for the query "seedance 2.5 api" on YouTube, read on 1 November 2026. The six below are the ones that speak to this question — every result from the vendor's own channel, plus every result titled as an instruction for reaching the API — listed in the order the page returned them. View counts are the numbers the page displayed at collection time, not an estimate of anything.

Three results are titled as instructions for reaching the API. Two name a platform in the title, and neither platform is the vendor; the third offers an "uncensored" route and names no platform at all. The vendor's own channel appears twice in the same sixteen and neither video is about calling the API: one is about Draft mode, one about 4K output. That asymmetry is the whole finding. The vendor documents the endpoint; the search results teach the platforms.

The 788,514 on the Atlas Cloud video is worth separating from the rest. It is the largest number in the list by a wide margin, and the title's claim — "API is live on Atlas Cloud" — is true in the sense that matters to Atlas: the model is live on their host. It is not a statement about the vendor's endpoint, and it is not presented as one.

What this does not settle

No account, no key and no call, so the claim that a reseller key fails on the vendor's host is inference from two error tables, not a measured 401. It is the first thing worth testing with a borrowed key on a throwaway request, and the result would either confirm the mechanism above or replace it with something more interesting.

Whether Atlas Cloud's "Official Endpoints" is a technical description — a pass-through to the vendor's host under a different front door — or a marketing phrase, was not determined. Their page distinguishes their inference host from their console host and never mentions the vendor's host, which is consistent with a wrapper and not proof of one. The same goes for Muapi and fal: a reseller can route to the vendor's API without the customer ever seeing the vendor's URL, and nothing on the pages read here says which of the two architectures is in use.

The prices on those platforms were not compared with the vendor's token rates here, and they should not be read off this page. And the reference value's absence from the tutorial prose is recorded as an inconsistency on 1 November 2026; it may be corrected, and if the prose is fixed, the table above still describes the behaviour the API reference documents.

Related on this site: Seedance 2.5 API free — whether the 2M token headline reaches this model at all, and which rows of the free-token table actually carry a number. Seedance 2.5 API pricing — the token meter, and what the vendor's own formula puts a second of output at. Seedance 2.5 audio reference — the reference_audio role used above, and the platform whose schema lists no audio field in any version.