Format reads inactive but still runs: the 409 codes

If GET /v1/formats shows a Format as inactive with api_trigger_enabled: false, do not stop there. Sume's docs say a Format you have never run over the API may read that way until its first run, and still runs. The real test is the call itself: a create that the owner has blocked answers 409 format_inactive or 409 format_api_trigger_disabled.

Reading the signal correctly

The two fields in the list are hints. The docs say both must allow API runs, that inactive or false refuses a create with 409, and that you should not gate your integration on polling them true.

What to do in code

Try the call. On a 409, read error.code and branch: the first two are the owner's setting and need a human on the owning workspace; the third is transient. Never treat a stale inactive in a listing as a reason to cache a refusal.

If you are the caller on a shared Format, you cannot change either setting: ask the owner. If you are the owner, change the setting on the API tab and retry the create.

• List for discovery, create for truth.
• Alert on format_inactive instead of retrying in a loop.
• Log error.code, not only the HTTP status.

Telling owners from callers

If you own the Format, the fix is two switches on the API tab. If you only call it, you cannot flip either; the useful thing to send the owner is the error.code, the Format address and the time. That is enough for them to find the setting and turn it on. Keep the message you show your own users free of internal detail: say the Format is temporarily unavailable.

Limits

The docs do not say how long a first run takes to flip the fields, so do not poll for it. And a 409 of this kind is a permission, not a capacity problem: waiting does not fix it. For capacity, workspace generation concurrency still applies to runs allowed by on_active_run: allow.