Publishing and scheduling

Every entry has a draft, which is all editing changes, and once published a published copy, which is all the delivery API serves to delivery tokens. An entry has unpublished changes while its draft is ahead of what's published. Preview tokens and the canvas see drafts.

What publishing checksCopy Anchor Link

Saving only checks that values have the right shape. Publishing also needs:

• every required field filled in for the default locale, and min blocks in a blocks field;
• every entry the content references or embeds to be published itself, so published content never points at a draft;
• every improve block to name a test or flag that exists in the environment.

The other way round, an entry can't be unpublished or deleted while published content still uses it.

Publishing some languagesCopy Anchor Link

In a space with several locales, Publish languages… (under Now in the publish options) publishes the changes of only the languages you pick: say the English text is ready and the Dutch translation isn't.

• The picked languages' values go live from the draft. The others keep what was published before, block by block; where nothing was published in a language, the delivery API falls back along the locale chain, as for any empty value.
• What isn't per language (the order of blocks, a new block, a shared field) is the draft's, since every language shares it.
• An entry is first published in its default locale; after that any language can go on its own.
• While some of the draft is unpublished, the entry's status is Changed. Publishing the remaining languages (or everything) makes it Published again.

Agents send { "locales": ["en"] } with POST …/entries/{id}/publish. Scheduled publishing, bulk publishing and approving a review publish every language.

Shared blocksCopy Anchor Link

Publishing a shared block updates every live page that shows it, without republishing each page. Its publish options list them: untick a page to keep it on the version it shows now, which gets the new one the next time that page is published (or Detach on its card to opt out for good). The reverse warning names the blocks a held page catches up on when it is published.

Approving a shared block in a reviewed environment shows the same list. A schedule keeps the pages picked when it was set. The publish sends one block.published webhook with the pages it updated.

SchedulingCopy Anchor Link

Publish in the entry bar opens its options: Now, or Later with a date and a time in your own time zone (Schedule for Thu 09:00). Schedule publish under Status beside the form sets both when the draft goes live and when it comes off your site, or clears them. Agents use POST …/entries/{id}/schedule with ISO 8601 times (the scheduleEntry MCP tool).

• At the publish time, the draft as it is then is published, not as it was when you scheduled it. Edits until then go live with it.
• Where publishing is reviewed, only the draft as it was when the admin scheduled it goes live. If anyone saves it after that, the run is refused; schedule it again once the new draft is reviewed.
• It runs as the person who scheduled it, with their role at that moment, and checks everything a publish does. It sends the same webhooks.
• If it is refused (a required field is empty, or the person lost their role), nothing changes and the reason shows under Status beside the entry's form.
• Schedules are checked every minute, so allow up to a minute.
• An unpublish time has to be after the publish time. Leave a time empty, or send null, to clear it.

A schedule belongs to one environment. Promoting an entry doesn't carry its schedule along.

HistoryCopy Anchor Link

Every save, every publish and every draft a promotion brings (Promoted) is kept as a version: History beside the entry's form, or GET …/entries/{id}/versions. Restoring a version makes it the draft again; publish to roll back. An entry keeps its newest 100 versions.

Deleting and the trashCopy Anchor Link

Deleting an entry (once nothing uses it) moves it to the Trash, linked under the entries list, for 30 days. Restore brings it back as a draft with its version history, at its old place when that is still free (at the root when its folder is gone); publish it again when ready. Delete for good removes it straight away. Agents use GET …/trash, POST …/trash/{id}/restore and DELETE …/trash/{id}.

Deleting a published entry takes it off the delivery API at once and sends entry.deleted; restoring doesn't publish it.

Moving and redirectsCopy Anchor Link

Edit under URL beside the entry's form gives a page or folder a new slug (per locale) or another folder. Its old path, and those of the pages below it, keep pointing at it as redirects: the delivery API answers an old path with where the page is now, so your site can answer with a 301 instead of a 404. Moving sends entry.moved with the previous paths. See Redirects for how they behave, adding one by hand, and answering them on your site.

DuplicatingCopy Anchor Link

Duplicate beside the entry's form (or POST …/entries/{id}/duplicate) makes a new draft next to the entry, with the same content type, folder and saved draft, " (copy)" after the name and, for a page, the first free <slug>-copy. Nothing is published.

Review before publishingCopy Anchor Link

An admin can make an environment's publishing reviewed under Settings → Publishing, typically production only. There, only admins publish, unpublish, schedule, delete published entries, and promote or import published content. Everyone else who edits sees Ask for review where Publish was:

1. Ask for review saves the draft and asks an admin to publish that revision, with an optional note. The entry shows "In review", the content list can filter on it, and an entry.review_requested webhook goes out, for a Slack message or an email from your own tooling.
2. Editing goes on as usual. If the draft changes after the ask, the request says so, and it can't be approved until it is asked for again: nobody publishes text they haven't seen.
3. An admin opens the entry and either approves, which publishes exactly the revision that was asked about, or sends it back with a reason, which the editor sees on the entry. Either way entry.review_closed goes out, and the activity log has it.

The person who asked can withdraw the request. An admin publishing an entry with an open request also closes it. Bulk actions, the canvas, editing on the site, the agent API, MCP and management tokens all follow the setting: whoever may not publish there asks for review (POST …/entries/{id}/review, and request_review in bulk), and publishing answers 403 review_required.

Several entries at onceCopy Anchor Link

Tick entries in the Content list to publish, unpublish, move, delete or promote them together (Promote opens promoting with them picked), up to 100 at a time (the box in the header ticks the whole page). Each entry goes through exactly what it would on its own: the same checks, history, webhooks and redirects, and deleted entries go to the trash.

The order you tick them in doesn't matter. A page that references an author publishes once the author has, and a folder is deleted after what is in it. Entries that wait on each other (each only names the others) publish together in one transaction: drafts like two articles linking to each other go live as a set, or not at all. That set is the whole cycle, even when it is larger than the 100 a call may name — a ring of 137 articles split over two calls still publishes from the half the call names (up to 500; a larger cycle says so), and the cycle's other entries go live with it. Whatever still can't be done is listed with the reason and stays ticked; the rest is done.

Agents use POST …/entries/bulk with { "action": "publish" | "unpublish" | "move" | "delete", "entryIds": [...], "parentId"? } (parentId for move, null for the root), which answers a result per entry.