Seasonal Format: a new slug per season, or edit the same one in place?
Edit one Sume Format in place and keep one address, or create a slug per season and keep each look reproducible. Contents API has no revert, which tips it.

If an old season's look must stay reproducible, create a new slug for each season. If you only ever want the current look, edit one Format in place. The Contents API commits changes but offers no revert, blame or history browsing, which makes in-place edits one-way unless you keep your own copy.
What each path gives you
POST /v1/formats creates a Format in your key's workspace with a slug and title, and returns skl_ ids and a vanity_invoke_url. A slug that your workspace already has is 409 skill_slug_taken, and a slug that a Format by Sume holds is 409 skill_slug_reserved.
| Question | Edit in place | Slug per season |
|---|---|---|
| Address your backend calls | One, unchanged | One per season; change a config value |
| Rerun last year's look | Only from your own copy of the files | Call last year's slug |
| Receipt format.version | Rises with each commit | Per-Format counter |
| Revert a bad edit | No API revert; recommit old files | Switch back to the old slug |
| Housekeeping | Fewer Formats | More Formats to list and cap |
A middle path
Edit in place for small copy changes, and fork a new slug when the structure of the recipe changes. Whichever you pick, store the receipt's format.version with every output so you can tell which edit made which video.
- Keep the package files in your own git repository; the API is a delivery path, not a history.
- Persist the opaque
skl_invoke_url; renamed handles keep resolving for 90 days. - Do not edit during a running queue unless you accept that items that start later read the newer package.
What to record either way
Whatever you choose, keep three things with each output: the Format invoke_url, the format.version from the receipt, and the package_sha you committed. With those, you can rebuild the state of a recipe from your own repository.
Also set the spend cap deliberately. A Format that never named a cap reports a platform default of $400, and a run can name its own cap up to $500, so a seasonal Format is a good moment to set a lower per-run number on the Format itself.
Think about who calls the Format too. If other people or systems call it by slug, a new slug means every caller must change, while an in-place edit changes behavior under callers who did not ask for it. Decide which surprise you can live with before the season starts.
Tradeoff
A slug per season costs setup and clutter, but it makes the audit trail honest. In-place editing is quicker, and loses the old recipe unless you saved it yourself.
Sources
Related posts
More in Formats
- Share one packshot across 100 bulk items with an asset_id
To reuse one product image in a 100-item Sume bulk run, upload it once and pass asset_id. Sume does not copy an asset_id or a media.sume.com URL again.
- Shorts series bulk queue finishes out of order: publish by number
Episodes in a Sume bulk queue run in parallel and finish in any order. Sort by an episode number in your output schema, not by completion time.
- Shorts series: episode video and thumbnail from one Format run
YouTube Shorts series take a custom thumbnail per episode. Bind one output schema so each Sume Format run returns the video and the thumbnail together.
- Can a Sume Format package hold a product CSV? Only five file types
A Format package accepts .md, .json, .yaml, .yml and .txt files. Put the product feed row in each run's input, not in the package. Here are the limits.
Written by Sume