Which Format version ran my API call? Check the receipt

To find out which Format version ran your API call, read the format.version field on the run receipt. A package edit does not change a run that has already started, so the receipt is your proof of which version produced a given video.

This matters the moment you edit a Format that something else is calling: a bulk queue, a script on a timer, or a teammate. Without the version on record, a good result and a bad result look identical until someone diffs the packages by hand.

A concrete example: you tighten the hook rules in a Format at 10:00 while a scheduled run fires at 10:05 and a bulk queue is halfway through. Three populations of output now exist, and only the version on each receipt can sort them.

What the receipt records

The run receipt returned by POST /v1/formats/{handle}/{slug}/runs, and again by the status and result URLs, includes a format object with a version. Store it next to the run id in your own table. The Format runs page lists the receipt fields, and the Call a Format page shows the request that creates one.

Two details keep you out of trouble. First, the invoke_url that starts with skl_ is permanent, while a renamed handle keeps resolving for 90 days. A caller using an old handle still reaches your Format, but you should not rely on that window. Second, the version describes what ran, not what is current. A receipt from last week will show last week's version even after you edit.

Editing a package while work is in flight

The Contents API writes the package as a commit. A multi-file PUT at the package root lands as one commit, and an If-Match header carrying the package sha makes a second editor fail with 409 format_package_sha_mismatch instead of silently overwriting you. The Format contents page covers both.

A run reads its package when it starts and is unaffected by later edits. In a bulk queue, every item is its own run, so the practical reading is that items already running keep the old package while items that start after your commit use the new one. Treat a mid-batch edit as creating two populations, and let the version field tell you which item belongs to which.

If you need a clean cut, the safest pattern is to pause what you control before the commit: stop adding items to your own queue, let in-flight runs finish, commit, then run one canary. The platform will not hold your runs for you, so the pause is your job.

What Sume does not give you

There is no revert, blame, or history browser in the API. If you want to go back, you PUT the older file content again, and that creates a new version. Keep your own copy of each package in source control, and record the receipt version beside the commit that produced it.

The table summarizes what to store and where it comes from.

A small routine for edits

Before you edit, read the package sha. Commit with If-Match. Then start one test run and confirm the receipt shows the new version before you release the batch or the schedule. If you promote a change by renaming rather than editing, remember that old callers keep working for 90 days, which can hide the fact that they still run the old recipe.

If two runs from the same afternoon disagree and you cannot say why, compare the version field first. It is the cheapest check in the whole debugging path, and it costs nothing.

Write the version into your review notes too. When a reviewer says the captions looked better on Tuesday, you can answer with the version that ran on Tuesday and the one that runs today, instead of guessing.