Skip to main content
Once a category or collection exists, you manage its title and its visibility through the company update endpoints. This guide covers renaming a row (and what happens to its slug), publishing and unpublishing it, and scheduling it to go live automatically at a future time. All operations here use PATCH /api/v202604/company/categories/{id} (or the collection equivalent) with a Bearer token carrying the storefront.update scope. Updates use PATCH semantics: only the keys you send are changed, and everything else is left as-is.

​
Rename a category

Send a new title inside the category object:

​
What happens to the slug

The slug is the canonical public identifier, so renaming has a deliberate effect on it:
  • If the category uses an auto-generated slug (the default), the slug regenerates from the new title on every title change. Renaming “Summer Sale” to “End-of-Summer Sale” changes the slug — and therefore the public URL — accordingly.
  • If the category has a pinned slug (custom_slug: true), the slug is permanent and a rename leaves it untouched.
To pin the slug so future renames don’t move the URL, send slug together with custom_slug: true:
On the authenticated surface, the response includes custom_slug so you can tell whether a row’s slug is pinned or auto-generated. This field is omitted from the public catalog.

​
Understand visibility

Two fields together decide whether a row is publicly visible:
  • active is a merchant on/off toggle. When false, the row is hidden from every public surface regardless of its status.
  • status is the lifecycle state: draft, scheduled, published, or archived.
A row is live — visible in the public catalog — only when active is true and its resolved status is published. There is no separate publish endpoint; you change visibility by updating these two fields.

​
Publish a row

To publish, set status to published (and make sure active is true):

​
Unpublish a row

To take a row off the public catalog, either flip active to false (a quick on/off that preserves the lifecycle state) or move status back to draft or on to archived:
Unpublishing changes what the public slug endpoint returns, and categories and collections differ. A non-live category returns 404 on its public slug. A non-live collection still resolves on its public slug unless it is archived — draft, scheduled, and inactive collections load (as noindex) so preview links keep working.

​
Schedule a row to go live

Scheduling is publish-in-the-future. Set status to scheduled and publish_at to the target timestamp:
The stored status stays scheduled until the time arrives. The go-live is applied at read time: once publish_at has passed, a stored scheduled row resolves to published in API responses automatically — you don’t make a second call to flip it. Combined with active: true, that makes the row live exactly at publish_at.
A scheduled category does not appear in the public catalog or resolve on its public slug until publish_at passes. A scheduled collection is not in the public catalog either, but it does resolve on its public slug beforehand (as noindex), which is useful for previewing a pre-launch page.
The spec models scheduling for going live only — there is a single publish_at timestamp and no corresponding “unpublish at” field. To take a row down on a schedule, make an update at that time setting active: false or status: "archived".

​
Collections

Renaming, publishing, unpublishing, and scheduling work identically for collections via PATCH /api/v202604/company/collections/{id}, using a collection object instead of category. The active/status/publish_at fields and the auto-go-live behavior are the same. The only differences are the ones noted above: collection public slugs stay resolvable for non-archived rows, and collections have no hierarchy fields.

​
Next steps