> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fluid.app/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> For new direct REST integrations, use the v2026-04 surfaces. The @fluid-app FairShare SDK continues to use its own published public-v2025-06 contract.
> Authenticate with the header Authorization: Bearer <token>; public storefront read endpoints require no auth.
> Lists use cursor pagination via the page[cursor] and page[limit] query params; follow meta.pagination.next_cursor until it is null.
> Never use /api/company/v1 or /api/v1 paths, page/per_page params, or offset pagination — they are legacy.
> The OpenAPI specs under api-reference/ are the authoritative contracts; prefer them over prose when in doubt. api-reference/storefront-v2026-04.yaml covers the v2026-04 storefront surface (/api/v202604/... paths); api-reference/auth-v0.yaml covers the unversioned auth surface (/api/... paths — authentication, MFA, social auth, and token exchange); api-reference/checkout-v2026-04.yaml covers the v2026-04 checkout surface (/api/checkout/v2026-04/... paths — carts, cart auth, discounts, items, subscriptions, orders, enrollments, and store config); api-reference/public-v2025-06.yaml covers the Public SDK surface used by the @fluid-app FairShare SDK, including its parallel cart lifecycle, browser integrations, versioned payment callbacks, unversioned public utilities, and the cart price-override operation; api-reference/payment-v2026-04.yaml covers the v2026-04 payment gateway admin surface (/api/payment/v2026-04/... paths, bearer-authenticated — gateway CRUD, gateway purchase/authorize/$0-verify, transaction list/show and capture/void/credit, and merchant payment configuration); api-reference/payments-v2026-04.yaml covers the v2026-04 cart payment surface (/api/payments/v2026-04/carts/{cart_token}/... paths, authenticated by the cart token in the path with no bearer — payment-method selection, VGS card tokenization, 3D Secure verification, and PayPal/Braintree/Klarna/Apple Pay flows); api-reference/commerce-v2026-04.yaml covers the v2026-04 commerce order-editing surface (/api/v202604/orders/{order_id}/edits paths, bearer-authenticated — post-checkout order edits that atomically insert items and add adjustments/discounts, with an optional dry-run preview); api-reference/webhooks-v0.yaml covers the unversioned webhooks surface (/api/... paths — webhook registration, delivery payloads, callback registrations, company events, and webhook/callback schemas).
> Successful responses wrap the resource payload alongside a top-level integer status and a meta object.

# Rename, publish, and schedule

> Rename a category or collection, control whether it is publicly visible, and schedule it to go live at a future time.

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:

```bash theme={null}
curl -X PATCH "https://api.fluid.app/api/v202604/company/categories/4821" \
  -H "Authorization: Bearer <your_token>" \
  -H "Content-Type: application/json" \
  -d '{
    "category": {
      "title": "End-of-Summer Sale"
    }
  }'
```

### 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`:

```bash theme={null}
curl -X PATCH "https://api.fluid.app/api/v202604/company/categories/4821" \
  -H "Authorization: Bearer <your_token>" \
  -H "Content-Type: application/json" \
  -d '{
    "category": {
      "title": "End-of-Summer Sale",
      "slug": "summer-sale",
      "custom_slug": true
    }
  }'
```

<Note>
  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.
</Note>

## 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`):

```bash theme={null}
curl -X PATCH "https://api.fluid.app/api/v202604/company/categories/4821" \
  -H "Authorization: Bearer <your_token>" \
  -H "Content-Type: application/json" \
  -d '{
    "category": {
      "active": true,
      "status": "published"
    }
  }'
```

## 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`:

```bash theme={null}
curl -X PATCH "https://api.fluid.app/api/v202604/company/categories/4821" \
  -H "Authorization: Bearer <your_token>" \
  -H "Content-Type: application/json" \
  -d '{
    "category": {
      "active": false
    }
  }'
```

<Warning>
  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.
</Warning>

## Schedule a row to go live

Scheduling is publish-in-the-future. Set `status` to `scheduled` and `publish_at` to the target timestamp:

```bash theme={null}
curl -X PATCH "https://api.fluid.app/api/v202604/company/categories/4821" \
  -H "Authorization: Bearer <your_token>" \
  -H "Content-Type: application/json" \
  -d '{
    "category": {
      "active": true,
      "status": "scheduled",
      "publish_at": "2026-07-01T08:00:00Z"
    }
  }'
```

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`.

<Note>
  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.
</Note>

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.

```bash theme={null}
curl -X PATCH "https://api.fluid.app/api/v202604/company/collections/5102" \
  -H "Authorization: Bearer <your_token>" \
  -H "Content-Type: application/json" \
  -d '{
    "collection": {
      "status": "published",
      "active": true
    }
  }'
```

## Next steps

* [Find and create categories and collections](/api/guides/find-and-create-categories-and-collections) — locate rows and create new ones.
* [Control country availability](/api/guides/country-availability) — limit a live row to specific countries.