Validate clip length against supported_durations before a Sume submit

Each Sume video model lists its allowed clip lengths in supported_durations, in whole seconds, and the lists are different: Seedance 2.0 allows 4 to 15, and the docs show other models with different windows. Validate the requested duration against the catalog entry for the exact model before you submit, or let a 400 tell you after the fact.

Do not hard-code a global range. A product that offers a slider from 5 to 10 seconds will be wrong for some models in both directions.

What the catalog says

The Seedance row is from the docs example response, read 2026-10-07. Other models are read from the live endpoint at run time; do not copy a table of them into your app.

Snap, do not guess

There are three policies when the requested length is not on the list. Reject, with a message naming the allowed lengths. Snap to the nearest allowed value, and show the user. Or choose another model that supports the length. The last one is the best fit when model is sume/auto, which lets Sume select the model.

Whichever you choose, do it on the client before the paid call, and keep the real list close: the catalog changes when models are added or retired, and an old copy gives wrong errors.

A Python snap helper

The helper takes a catalog entry as a dict, so you can feed it the live response. The sample list is the Seedance 2.0 one.

def snap(entry, wanted):
    allowed = sorted(entry.get("supported_durations") or [])
    if not allowed:
        return None
    if wanted in allowed:
        return wanted
    return min(allowed, key=lambda d: (abs(d - wanted), d))


seedance = {"id": "seedance-2", "supported_durations": list(range(4, 16))}
print(snap(seedance, 2))
print(snap(seedance, 8))
print(snap(seedance, 30))

Price follows seconds

Cost scales with the seconds you ask for, so snapping up costs more and snapping down costs less. Show the estimate for the snapped value, not for the number the user typed. The usage ledger records what was reserved and captured per job, so you can reconcile later.

Where to run the check

Run it in two places: the form, so a user sees allowed lengths as soon as they pick a model, and the server, right before the paid call. The server check is the one that matters, because a stale browser tab can still send an old value.

A related check is the resolution list, which the catalog also publishes per model. Validate duration, resolution and aspect ratio together against one entry, then estimate the cost of the exact combination you will send. Three small checks in one function beat three separate 400 responses.

Cache the catalog for a few minutes, not days. A model added or retired changes the list, and the catalog endpoint is cheap to read.

• Whole seconds only; supported_durations is a list of integers.
• Treat an empty or missing list as "ask the catalog again", not as "anything goes".
• Record the value you actually sent next to the job.