Which Sume video models take 9:16? Query the catalog, do not guess

Ask the catalog. GET /v1/videos/models returns, for each video model, supported_aspect_ratios, supported_durations and supported_resolutions, and Sume validates every request against those lists. A model that does not list a value returns a 400, so a filter on the catalog is the cheapest compliance check you have.

The filter

This shell line lists models that take 9:16 and the longest duration each lists. It needs jq.

curl -s -H "Authorization: Bearer $SUME_API_KEY" https://api.sume.com/v1/videos/models \
  | jq -r '.data[] | select(.supported_aspect_ratios | index("9:16")) | "\(.id) max=\(.supported_durations | max) res=\(.supported_resolutions | join(","))"'

What to expect

The table below is from the Video Router doc and the catalog source, so run the filter for the live answer. Three rows list no aspect ratio at all and reject aspect_ratio if you send one, because the source video or image sets the frame.

Why this beats a hard-coded list

Platform specs and model catalogs both change. YouTube's Shorts page says vertical and up to 3 minutes, and TikTok's page recommends 9:16, so you want vertical, but the set of models that offer it is Sume's to change. A pipeline that reads the catalog at submit time breaks on a missing value with a clear 400 and not with a stretched clip. Keep the filter in your job runner and log what it returned.

The no-aspect-ratio explainer covers the three rows that cannot be reframed by request.

Reading the catalog at runtime

Fetch the catalog once per job run and cache it for the run, not for days. Then validate your own request against it before you submit: is 9:16 in supported_aspect_ratios, is your duration in supported_durations, is your resolution in supported_resolutions. That mirrors what the API does and lets you fail in your own code with a clear message.

Watch one detail. The Video Router catalog can list values such as auto and adaptive that the OpenRouter-shaped /v1/videos descriptor leaves out, because the descriptor advertises only values a caller may send as aspect_ratio. If you read the legacy catalog, filter to real ratios yourself.

A last use of the catalog is cost. It carries pricing_skus, the Sume billable rates, so one pass can rank the models that pass your filter by price. That is a better basis for choosing than a table in a blog post, including this one.

Limits of this check

The catalog tells you what the API accepts, not what a platform accepts. It says nothing about file size or bitrate, and the platform pages differ on those. Pair it with a check of the finished file.