One API key for Seedance 2.5, Wan 3.0, Kling 3 and MiniMax H3

You do not need a separate vendor account to call Seedance 2.5, Wan 3.0, Kling 3 or MiniMax H3 through Sume. One Sume API key, sent as Authorization: Bearer $SUME_API_KEY, covers all four, and one workspace USD balance pays for them. You pick the model with a single field, model, on POST /v1/videos.

This is described in the Sume video generation docs and the Video Router docs, read on 2026-10-06. The vendor timeline, for context, is on Magic Hour's tracker: the models come from different companies and launched in different months, which is exactly the integration work a single surface removes.

What stays the same across models

The wire format follows the OpenRouter video generation API field for field, so a client written from those docs works after you change the base URL and the key. The differences are listed in Sume's docs and are small.

What changes between models

Limits differ, and the API enforces them rather than guessing. Seedance 2.5 takes 4 to 30 seconds, Wan 3.0 takes 2 to 30, Kling 3 takes 4 to 15, and MiniMax H3 takes 5 to 15. Kling accepts 720p and 1080p in 16:9, 9:16 and 1:1; H3 is native 768p. If a value is outside what the model lists, the answer is 400 unsupported_capability, not a silent change.

A few fields are rejected everywhere on purpose: seed, size and a non-empty provider.options return 400 unsupported_parameter. If you ported code from a provider SDK that sets a seed, remove it. Use resolution and aspect_ratio instead of size.

Switching models is one string

The same request body runs against each id as long as the values fit that model's limits. This loop submits one prompt to four models and prints the job ids. It needs a funded workspace, because each submit reserves its price.

import os, requests

H = {"Authorization": f"Bearer {os.environ['SUME_API_KEY']}"}
body = {
    "prompt": "A barista pours oat milk into an espresso, steam rising, morning light",
    "duration": 5,
    "aspect_ratio": "16:9",
}
for model, res in [("wan-3.0", "480p"), ("seedance-2.5", "480p"),
                   ("kling-3", "720p"), ("minimax-h3", "480p")]:
    r = requests.post("https://api.sume.com/v1/videos", headers=H,
                      json={**body, "model": model, "resolution": res}, timeout=60)
    print(model, r.status_code, r.json().get("id") or r.json())

What this means for cost and control

One balance means one place to see what you spent, and one place to run out. A 402 insufficient_credits means the workspace balance is below the reserve for that job; fund the workspace or reduce the request, then resubmit. Because jobs are reserved at submit and captured on completion, a failed job is refunded rather than billed.

It also means one place to rotate a key. If a key leaks, you replace one credential, not four. The cost of this convenience is the 1.25 multiple on the provider list price that Sume applies to every video row; the figures in a blog table are not a substitute for the live catalog, which lists the exact rate for each id.

What you give up by not holding a vendor account

A direct vendor account can offer features that a shared surface does not expose. Sume's catalog does not accept seed, does not pass provider-specific options through, and does not offer every mode of every model: Kling 3 on this route takes text, first and last frames, and no reference inputs. If you depend on a vendor-only parameter, a direct account is the way to get it, and the Sume docs list the omissions plainly instead of hiding them behind a silent fallback.

For most teams building an ad, a product clip or a short, the trade is worth it: no vendor accounts to open four times, and the same polling and webhook code for every model. The one-key surface is most useful when you are still deciding which model fits, because the switch is a string and a price check.