Format works in chat but fails over the API? The approval gate

A Sume Format that pauses for approval in chat runs unattended over the API. See what changes, why unattended_blocked appears, and a pre-flight list.

5 min readSume
All posts

A Format that works in chat can fail over the API because nobody is there to approve anything. In the chat UI, "approve these stills before I make the video" is a quality gate by design. Over the API, Sume tells the run those approvals are already granted, so it goes straight on to the paid step within its spend cap.

When a run really cannot finish without a person, it comes back failed with unattended_blocked, never as a half-finished completed. This post lists what differs between the two modes, using Create a run and Errors and spend.

What changes when you move from chat to the API

The Format's recipe is the same. The caller is different, and so are the guardrails.

Chat run against API run (Create a run page, read 2026-10-10)
TopicIn the chat UIOver the API
Approval gatesA person approves stills, scripts or plansTreated as already granted
Missing inputThe run asks you in chatunattended_blocked, run failed
Matching an avatar to the briefCan ask which avatarIf none matches, unattended_blocked
Cost controlYou watch the threadgeneration_spend_cap_usd, up to $500
Result shapeA person reads the threadoutput projected onto your schema
FailureDraft may stay completedProjection failure is a run failure

Move every question into input

The most reliable fix is to answer every question the chat would have asked. The input object is caller data, up to 64 top-level keys and 2 MiB, and Sume writes it whole to a file the agent reads. Put the product URL, the host image, the script and the chosen avatar there. Keep instruction for the task itself, since only the first ~4000 characters of it reach the run as prompt text.

Do not paste scraped text into instruction. The docs call the input file a trust boundary, not a sandbox: runs are spend-capped, which limits the blast radius of a hostile payload, but untrusted text should not be passed through on purpose.

Read the receipt in the right order

A run that completed always did real work and always fills artifacts[], but it can still carry output_error when the projection did not match your schema. Check output_error before you read output. On a failed run, primary_output_url is null, so if (run.primary_output_url) stays a safe test for "the deliverable exists".

For unattended_blocked, the structured-output page says the harvested media are intermediates, not the finished cut, and that assembled_deliverable is false. Show them for debugging but do not publish them.

Pre-flight checklist

Run through this once per Format before you call it from code.

  • Does the Format ask for a person, an avatar or a file the run cannot find? Supply it in input or attachments.
  • Is generation_spend_cap_usd set for this run, and is it above what the brief needs?
  • Does your output_schema make optional media nullable, so a partial result is legal?
  • Is the API call trigger switched on in the Format's API tab, and does your key carry formats:write?
  • Is the Idempotency-Key derived from your order id and a version you bump on purpose?

Sources

Related posts

More in Formats

All Formats posts

Written by Sume