App demo video through the sume-mobile-app-ugc Format: what to send

For an app demo video you can call sume-mobile-app-ugc, one of the slugs that the Sume Format catalog lists at the sume handle. The call is POST /v1/formats/sume/sume-mobile-app-ugc/runs. Sume's own definition of the Format declares text as its input kind and video as its output kind, but the catalog docs tell you to read the Format with GET first rather than guess, because input is free-form and the Format reads only the keys it knows.

Step 1: read the Format

GET /v1/formats/sume/sume-mobile-app-ugc returns the description and the io profile. input_kind is one of url, text, image or product, and output_kind is one of video, image or text. For Formats saved before registration existed, io is null, which means not declared. Use the description then.

Step 2: send what the demo needs

There is no published field list for input, so describe the app in plain keys and say in instruction which ones matter. Screens go in as images. The attachment budget is 30 files per run, so choose the screens that show the one flow you want to demonstrate.

• attachments: three to six screenshots of the flow, in order.
• input: app name, the one-line promise, the store URL.
• instruction: length, aspect ratio, tone and what must not appear.
• generation_spend_cap_usd: a number you choose per run.
• Idempotency-Key: app name plus version of the brief.

Step 3: check what came back

The receipt records what ran. Check these fields before you publish.

What not to expect

Runs over the API are unattended. A step that asks for a person to approve a still is treated as already approved, and the run goes on to the paid step inside its cap. If the run cannot finish it comes back failed with a code such as unattended_blocked, and never as a half-finished completed.

Checks before you publish

An app demo has a specific risk: the video can show a screen or a flow that the app does not have. Compare the result with the real app before you post it. The name of the Format suggests a creator-style clip, but its description is the authority, so read it with the GET call and not the slug alone.

Keep the brief short and put the flow in order in instruction: open, first action, result. Send the store URL and the app name in input as data. If the first run is close, continue it with previous_run_id and say what to change. Each continuation has its own receipt and cap, so a demo with three small fixes is four runs, each with its own usage to read.