Publishing

To publish an entry, choose Publishing → Publishing Queue in the sidebar, then Publish now in the entry's ⋯ menu. Content sets the entry to Published with today's publish date, saves a version of it and calls your webhooks for entry.published. It confirms that the entry "is live".

To take a published entry down, choose Unpublish in its ⋯ menu. The entry goes back to Draft, leaves the queue and its public page, and Content calls your webhooks for entry.unpublished. Neither action asks you to confirm first.

A published entry's ⋯ menu also has View page, which opens its public page in a new tab. Publishing and unpublishing need the Publish an entry or page permission, which the Owner, Admin and Editor roles have.

An entry is live when its status is Published. Only published entries reach the delivery APIs and have a public page. There are four ways to publish one:

• Publish now in the Publishing Queue. It saves a version and calls your webhooks.
• Approve in Editorial → Review Queue, for an entry that's In review.
• Setting Status to Published in the entry editor's Visibility tab and saving.
• A scheduled date: Content publishes a Scheduled entry once its date arrives, and saves a version of it.

Webhooks are called only when you publish or unpublish from the Publishing Queue. Each way needs the Publish an entry or page permission. Content library covers the entry editor and scheduling, and Editorial covers the Review Queue.

Publishing → Publishing Queue lists every entry that's Scheduled, In review or Published. Each row shows the entry's slug and type, its go-live date if it's scheduled, its status, and a date: the scheduled date, the publish date or the last update, in that order of preference.

The figures across the top show how many entries are In queue (with how many scheduled entries are due now), then Scheduled, In review and Published. Filter by status, which starts on All Statuses, and search titles, slugs and excerpts. The list shows 25 entries a page; switch to 10, 50 or 100 at the bottom.

Two screens list the project's 100 most recent versions, across every entry, newest first. A version is taken when you publish from the Publishing Queue, when a scheduled entry goes live, and when you save in the Structured Editor.

• Publishing → Releases shows each version's entry and date, its version number and the title it saved. Search entries and version numbers. The figures across the top show Total versions, Versioned entries and the Latest snapshot.
• Publishing → Publishing History shows the same versions with the entry's slug. Narrow it to one entry with the entry filter (All entries to start), and search titles and slugs. The figures across the top show Snapshots, Entries and the Latest publish.

On either screen, Restore as draft in a version's ⋯ menu puts that version's title, slug, type, excerpt, body, author, locale and cover back on the entry and sets it to Draft. It happens straight away, without asking, and never publishes. Restoring a published entry takes it out of delivery, so it needs the Publish an entry or page permission.

An environment is a named delivery target, such as production, staging or preview. To add one, choose Publishing → Environments, then Create environment. Only the Name is required; the Key fills in from it, in lowercase with underscores. The project's first environment becomes its default.

Each environment's ⋯ menu has Rename, which keeps the key, Duplicate, which adds "_copy" to the key, Set as default and Delete, which asks you to confirm first. The figures across the top show Total environments, the Default one and the Others. Search names and keys.

Sites in Publishing → Sites & Brands can name an environment. Changing environments needs the Manage settings permission, which the Owner and Admin roles have.

Your apps read published entries through the project's public delivery API, which needs no sign-in and never returns drafts. Publishing → Edge Delivery shows the project's Public REST endpoint; the copy icon beside it copies the full address. It also lists the project's environments and its 100 most recently published entries, each with a View link to its public page.

Public responses and public entry pages are cached for up to 60 seconds, so a change can take up to a minute to show. To refresh an entry sooner, use Cache Invalidation. Publishing → Delivery APIs lists the public endpoints with their cache rules. Developer tools covers querying the delivery APIs.

To make the next read of an entry fetch fresh content, choose Publishing → Cache Invalidation, pick the entry in Published entry and choose Invalidate cache. Content expires the cached delivery data for that entry and the project. It doesn't purge outside CDNs, so their copies can last until their 60-second limit runs out.

Invalidation history lists every request with its path, its status and when it was made, and each request is also recorded in the project's audit log. The figures across the top count Published entries, Requests and the Last request. Invalidating needs the Publish an entry or page permission.

A webhook tells another system when an entry is published or unpublished, for example to rebuild a site. To add one, choose Publishing → Webhooks, then Create webhook:

• Name: required, like Site rebuild.
• URL: required, and it has to start with http:// or https://.
• Events: pick at least one. Content sends entry.published, which starts selected, and entry.unpublished.

Choose Create webhook. New webhooks are Active. When you publish or unpublish from the Publishing Queue, Content sends a POST request with a JSON body to every Active webhook that subscribes to that event, like { "event": "entry.published", "payload": { "entryId": "…", "slug": "…", "title": "…" }, "sentAt": "…" }.

Each webhook's ⋯ menu has Edit, Send test, Duplicate (a Paused copy), Pause or Resume, and Delete, which asks you to confirm first and keeps the webhook's past deliveries in the log. Changing webhooks needs the Manage settings permission, which the Owner and Admin roles have.

Send test in a webhook's ⋯ menu sends an entry.published request whose payload is { "test": true, "webhookId": "…" }, and Content says whether it succeeded or failed, with the HTTP status.

The Delivery log under the webhooks lists the 50 most recent attempts, newest first: the event and its time, the webhook, the status (Delivered or Failed) and the response code. Content tries each delivery once and doesn't retry a failed one. The figures across the top count Total webhooks (with how many are active), recent Deliveries and Failed ones. Search webhooks by name and URL.

Publishing → Sites & Brands records the sites the project publishes to. To add one, fill in Add site: Site name and Hostname are required, Brand name is optional, Environment starts as No environment, and Status is Draft, Active or Paused (Draft to start). Choose Add site. Each hostname is used once, and the environment has to belong to the project.

A site's ⋯ menu has Edit, which loads it into the form with Save changes and Cancel edit, and Archive, which hides it from the list straight away. Sites are records for your team: hosting and DNS stay with your deployment provider. Only project owners can add or change sites.