Read the Seedance 2.0 catalog row on Sume, field by field

One JSON object in the response of GET /v1/videos/models tells you everything you need to build a valid Seedance 2.0 request on Sume, if you know how to read it. The docs print a sample row for seedance-2, and each field in it maps to a rule: 4 to 15 whole seconds, three resolutions, six aspect ratios, first and last frame images, image, video and audio references, audio on by default, no seed, and no passthrough parameters.

This post reads that row from top to bottom, so you can apply the same method to any other model. The row is a documentation sample, so read the live endpoint before you hard-code anything, and note that the docs also say seedance-2 offers 1080p.

The row, field by field

Values below are from the sample in the Sume video docs, read on 2026-10-03.

Turning the row into a validator

A twelve-line check covers most failed submits. Reject a duration that is not in supported_durations. Reject a resolution or ratio that is not listed. Reject a frame_type that is not in supported_frame_images, and a reference whose type is not in supported_input_references. If seed is false, drop the field. If supported_sizes is null, never send size.

The same logic works for every model because the field names are shared; only the values change. That is how the docs can say that seedance-2.5 accepts 4 to 30 seconds, wan-3.0 accepts 2 to 30 and minimax-h3 accepts 5 to 15 without different request shapes.

What the pricing field is

The sample shows pricing_skus with a key of per-1000-video-tokens and a value of 0.0154. That is a provider-side SKU in the docs example. Sume's billing page says the workspace is charged the provider list times 1.25 on every model and that usage.cost on the job is the Sume billable amount. So do not multiply the sample by a duration and call it a quote; use the admission preview or a small test job to see what a real request reserves.

Using the same method on another model

The method is the same for any other id on the list. Fetch the row, read the lists, and write the request from them. Models differ in the values they accept, so a value that works on one row can be absent from another.

Keep a copy of the row you validated against in your test fixtures. When a model changes, a failing fixture is a better alarm than a user report.

Limits

The row is an example from documentation and the catalog changes, so no value above is a promise about today's live list. The created value, 1767225600, is a Unix timestamp; it is an informational field, and the docs do not say how it is used.