How-to library · Developer docs

How-to library

Task-shaped pages: a title that starts with a verb, the situation in a few lines, the steps, the working code in both engines, and why this way rather than another. Found from a search, done, and left.

How-to APIs and JavaScript

Schedule a page to go live, and to come down

Published

A published date in the future schedules the go-live, and unpublishAt schedules the take-down. Send ISO dates with their offset, expect them back in UTC, and check signed out: until the date, the page answers 404 to visitors.

Context

Context. A campaign page must appear at nine on Monday and disappear at the end of the month, and nobody wants to be awake to press the button. On pages, books, blog posts, FAQ records and custom entity records, published is a date, not a switch: a date in the future is a scheduled go-live. unpublishAt is the date it comes down.

Before you start

Credentials for a backend user who may publish, and the record's id. The content you want live at that moment must already be the record's live revision: scheduling publishes the record, it does not choose a revision.

Steps

  1. Make the content right first: the live revision is what goes public at the date (Change one area).
  2. Send published and, if it should come down, unpublishAt, as ISO 8601 dates with an offset, at the top level of the body.
  3. Read them back in the same request with properties. The platform stores and returns them in UTC, so 09:00+11:00 comes back as 22:00+00:00 the day before.
  4. Check the page signed out: until the go-live it answers 404.
  5. To cancel, send null for both.

Code

HTTP 
PUT /cdna-api/pages/page/1885?properties={id,published,unpublishAt,publishAt}
Content-Type: application/json

{"published": "2026-12-01T09:00:00+11:00", "unpublishAt": "2026-12-31T17:00:00+11:00"}
JSON 
{
  "result": "success",
  "data": {
    "id": 1885,
    "published": "2026-11-30T22:00:00+00:00",
    "unpublishAt": "2026-12-31T06:00:00+00:00",
    "publishAt": null
  },
  "message": "The Page has been saved successfully."
}

The real answer on this site's sandbox page; a signed-out request for the page answered 404 straight after. Cancelling was {"published": null, "unpublishAt": null}, which answered both as null.

Why this and not that

Not publishAt: the field exists and is saved, but the scheduler does not read it, so a page given only publishAt never goes live. Not "published": true with a job that edits it later: true means now, and the schedule needs nothing running on your side. And not a date without an offset: which zone it is read in then depends on the server's settings, so say the zone and read the answer back. When the date passes, the platform changes nothing in the record, which is why nothing fires at that moment; the events that jobs listen to for a go-live arrive afterwards, from the platform's scheduled publishing task (Going live).

Go deeper
GuideMaking a revision live, rolling back and publishing GuideScheduling content ReferenceEdit a page: API reference

Was this page helpful?

Your answer goes to the docs team.