Video generation API

Endpoints and authentication

Video lives on the OpenAI-compatible entry point and uses the same key as text models: only the path changes. The Anthropic entry point does not generate video.

The key goes in Authorization: Bearer sk-your-tokenator-key. There is no separate video key — generations are drawn from the same key as tokens.

Your first request

curl https://api.tokenator.top/v1/videos \
  -H "Authorization: Bearer sk-your-tokenator-key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "seedance-2.0-mini",
    "prompt": "a neon city in the rain, slow camera fly-through",
    "duration": 6,
    "resolution": "720p",
    "aspect_ratio": "16:9"
  }'

The answer arrives once the clip is ready and looks like any other generation response: a data array of links.

{
  "created": 1755600000,
  "data": [
    { "url": "https://generated-video.tokenator.top/6f2c1a9b.mp4" }
  ]
}

The response carries exactly two fields: created, a unix timestamp, and data, one entry per requested clip. An entry has either url or b64_json — the whole file in base64 when the model answered inline. The proxy adds nothing else.

The link points at a separate file host — generated-video.tokenator.top, straight from the root of the host. It is neither the API address nor the provider's temporary URL: the file was downloaded and rehosted on our side, is served with Cache-Control: immutable and lives as long as it sits on the service's disk.

Which models do video

The API returns the same list — with durations, resolutions, aspect ratios and defaults. That is safer than hard-coding parameters: the list changes together with the catalog.

curl https://api.tokenator.top/v1/videos/models \
  -H "Authorization: Bearer sk-your-tokenator-key"

{
  "object": "list",
  "data": [
    {
      "id": "seedance-2.0-mini",
      "object": "video_model",
      "durations": [4, 6, 8],
      "resolutions": ["480p", "720p", "1080p"],
      "aspect_ratios": ["16:9", "9:16", "1:1"],
      "audio": true,
      "image_input": true,
      "default_duration": 4,
      "default_resolution": "720p",
      "default_aspect_ratio": "16:9",
      "cost": {
        "480p|4": 1,
        "720p|4": 2,
        "720p|8": 4,
        "1080p|8": 8
      },
      "cost_default": 2
    }
  ]
}

Request parameters

Fields you leave out are filled from the model's defaults, and values outside the declared list are refused before the provider is contacted — a rejected attempt costs no generations. The callback_url, webhook_url and provider fields are stripped and never forwarded upstream: callbacks would bypass your key.

How long it takes and what happens inside

A render takes from tens of seconds to a few minutes. The request is synchronous: the connection is held until the clip is ready, and to keep intermediate proxies from closing it on silence the service pads the response body with keep-alive whitespace. The final JSON arrives as the last chunk — an ordinary parser reads it as-is.

When the provider answers with an async job, the proxy polls it and returns the finished clip — you do not need your own polling loop. The total wait is capped at 15 min; after that you get a 504, the claimed generations are returned to the key, and the answer carries the upstream job_id — the render is still running, and GET /v1/videos/{id}?model=… picks up its result when it is done.

The practical consequence: raise your HTTP client timeout to 15 min and do not retry on timeout — a repeat request starts a second render.

curl "https://api.tokenator.top/v1/videos/vid_123?model=seedance-2.0-mini" \
  -H "Authorization: Bearer sk-your-tokenator-key"

The model parameter matters here: it selects the provider to ask for the status. Without it the request goes to the first enabled video model.

Starting frames and references

Models that declare image input can animate an existing frame. Images go in frame_images, style or character references in input_references; at most four in total per request. Some models take links instead, in reference_image_urls (up to five), reference_videos and reference_audios (three each) — those fields travel upstream untouched, while the counts and the link scheme are checked on our side. If the model declares no image input, the request is refused with a 400 — before any generation is claimed.

The first and the last frame are a separate pair of fields: first_image_url and last_image_url, one link each. The clip starts from the first frame and arrives at the last; either one alone is fine. The link has to be public — http(s) or data: — and it can point anywhere, the file does not have to be uploaded to us. The model has to declare the frame, which its catalog entry says, otherwise 400. Vendors expect different shapes for this; the proxy rewrites the request into whichever one the chosen upstream reads, so these two fields are all you need.

{
  "model": "seedance-2.0-mini",
  "prompt": "the camera slowly pushes in, wind moves the leaves",
  "duration": 4,
  "frame_images": ["https://example.com/frame.jpg"]
}

{
  "model": "seedance-2.0-mini",
  "prompt": "a smooth transition, the camera stays put",
  "duration": 5,
  "first_image_url": "https://example.com/first.jpg",
  "last_image_url": "https://example.com/last.jpg"
}

SDKs and ready-made examples

The video endpoint is not part of the typed surface of the OpenAI SDKs, so the convenient way to call it is a raw request. The key and the base URL stay the same as for chat — no separate client needed.

from openai import OpenAI

client = OpenAI(
    api_key="sk-your-tokenator-key",
    base_url="https://api.tokenator.top/v1",
    timeout=900,
)

result = client.post(
    "/videos",
    body={
        "model": "seedance-2.0-mini",
        "prompt": "a neon city in the rain",
        "duration": 6,
        "resolution": "720p",
    },
    cast_to=dict,
)

print(result["data"][0]["url"])

import requests

response = requests.post(
    "https://api.tokenator.top/v1/videos",
    headers={"Authorization": "Bearer sk-your-tokenator-key"},
    json={
        "model": "seedance-2.0-mini",
        "prompt": "a neon city in the rain",
        "duration": 6,
        "resolution": "720p",
    },
    timeout=900,
)
response.raise_for_status()
print(response.json()["data"][0]["url"])

const response = await fetch("https://api.tokenator.top/v1/videos", {
  method: "POST",
  headers: {
    Authorization: "Bearer sk-your-tokenator-key",
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    model: "seedance-2.0-mini",
    prompt: "a neon city in the rain",
    duration: 6,
    resolution: "720p",
  }),
  signal: AbortSignal.timeout(900_000),
})

const result = await response.json()
console.log(result.data[0].url)

Ready-made snippets with your own key and address are in the key dashboard, next to the chat ones.

How video is billed

Video does not spend tokens. A key carries a separate video-generation counter, and one generation is one clip at the base resolution and the base duration. Heavier parameters cost proportionally more: the resolution multiplier is set by the operator (say 480p — 1×, 720p — 2×, 1080p — 4×), and duration scales against the base one. The final charge is clips × model multiplier × resolution multiplier × duration multiplier, rounded up.

You do not have to do the arithmetic: /v1/videos/models returns a cost field per model — a list of {"resolution", "seconds", "price"} objects, one per combination (carrying aspect_ratio too when the aspect ratio moves the price) — plus cost_default for the default parameters. When the resolution is given as a size, the price follows the short side: 1920x1080 is 1080p.

Generations are claimed before the provider is contacted and returned if no clip arrives: a failed render costs nothing. Video bundles are sold separately from tokens; a key with token_limit: -1 is a generation-only key with no access to text models.

curl https://api.tokenator.top/v1/tokens \
  -H "Authorization: Bearer sk-your-tokenator-key"

{
  "name": "my-key",
  "limit": 1000000,
  "used": 240000,
  "remaining": 760000,
  "image_limit": 0,
  "image_used": 0,
  "image_remaining": 0,
  "video_limit": 20,
  "video_used": 3,
  "video_remaining": 17
}

Limits

• One clip per request: an n above 1 is clamped to 1.
• A clip is at most 60 seconds long, and never longer than the model declares.
• At most four input images per request (frame_images and input_references combined).
• References: up to five images (reference_image_urls), up to three videos and up to three audio files. The links must be http(s) or data:; anything else is refused with a 400 before a generation is claimed.
• Some models cannot render from a prompt alone: their catalog page says «Reference: required», and a request without reference_image_urls / reference_videos / frame_images is refused with a 400 immediately, without touching the provider.
• Concurrent renders per key: 1. A request beyond that is not queued — it gets a 429 with a busy_for_seconds field.
• The total wait for one request is capped at 15 min.

Errors

Trying it without code

The key dashboard has a Studio with an Images / Video switch: duration, resolution and aspect ratio are picked with buttons and finished clips land in a gallery. It is the same endpoint and the same generation counter — a convenient way to try a model before writing an integration.

FAQ

Read next