Private Pages

private is a flag on a page, and it has exactly two effects. A private page appears in nobody’s page list except the list of the person who created it, and it can never be published — not by scheduling it, not by an Administrator, not at all. It is not a plan feature: private does not appear in Leed’s entitlement catalog anywhere, so it behaves identically on Free, Starter, Growth and Enterprise.

Who can see a private page

Every page list Leed builds ends with the same step: drop any page whose private flag is set, unless the person asking is the one who created it. That step runs for every role. There is no privilege that turns it off and no override that satisfies it — the comparison is against the page’s creator and nothing else.

The count shown above the page tree is adjusted along with the list, so the tree does not advertise pages you cannot open. Everything else that decides which pages appear there — page type, labels, soft deletion, search terms — is covered in Managing Pages.

Why it can never go live

The page record says so in the schema itself: “Private pages cannot EVER be published.” Two separate mechanisms hold that line.

In the page editor, the document header works out whether to offer a Publish control at all, and the private flag is the first thing it looks at — before your role and before your overrides. On a private page the control is not rendered, so there is nothing to click and no error to walk into.

flowchart TD
    A["Page is marked private"] --> B["Editor header:<br/>no Publish control is rendered at all"]
    A --> C["Publish path:<br/>the provider reads the flag"]
    C --> D["Throws a conflict before the<br/>revision can flip to PUBLISHED"]

The header check is the one you see; the publish-path check is the one that matters, because it holds even if the control were reached another way.

At the far end, the publish path refuses outright. When a deployment reaches the step that flips a page’s revision to PUBLISHED, the provider reads the flag and throws a conflict:

409 ConflictError - Cannot publish private page 8f2c1b40-3d97-4a52-9f0e-6c1d5b2a77e1.

Note where that fires. It is not the request that schedules the page — POST /api/page/:pageId/schedule does not check the flag, so a private page pushed into the publish queue over the API is accepted at the time and fails the deployment that would have carried it. Because the editor never offers the control, that route is only reachable from an integration.

For the rest of the publish path and the states a page moves through on its way to the live site, see Publishing and Scheduling a Page.

How a page becomes private

The flag is written in exactly one place: the call that creates the page. POST /api/page accepts private in the body and stores it on the page record.

{
  "pageTypeId": "u05nxr",
  "title": "Q3 pricing scratchpad",
  "private": true
}

After that there is no supported way to change it. The page-update endpoint (PUT /api/page/:pageId) accepts private in its request schema, and so does the update_page_draft MCP tool, which mirrors that schema — but the update writer only touches the page’s current revision, and private lives on the page record rather than on the revision. The value is dropped with no error and no effect. Neither MCP tool that creates a page exposes the field at all, so over MCP the flag is unreachable in both directions.

The practical reading: private is decided when a page is created and is permanent for that page. To take a page out of the private state, copy its content into a new one.

The MCP page tools — including the update tool whose schema carries a field it cannot write — are documented in MCP Tools: Pages and Content.

Finding private pages

The page list endpoint takes a private query parameter. true returns only private pages, false excludes them, and omitting it returns both.

GET /api/page?private=true

Two things to know before you build anything on it. The creator filter still runs afterwards, so private=true returns your own private pages and no one else’s — there is no listing anywhere, in the CMS or over the API, that shows every private page in a workspace. And the parameter is compared against the literal string true, so ?private=1 and ?private=yes are both read as false and quietly hand you the opposite list.

The filter is an API query parameter, not a control in the page tree’s filter popover, and it is not exposed on the list_pages MCP tool, which accepts a label and a page type only.

Private pages and a Restricted member

Both filters run on the same list, in a fixed order. The Restricted filter goes first and reduces the list to the pages that member can reach through an override at Read level or better; the private filter runs after it and applies to everyone.

That order produces two results worth spelling out. A Restricted member with a page-type override sees the pages of that type — apart from anyone else’s private ones, which the second filter removes. And a Restricted member sees their own private pages only if those pages also survive the first filter: a private page they created under a page type they hold no override on is dropped before the creator check is ever reached.

How the rest of the tree is narrowed for a Restricted member is in Who Can See What.

What private is not

It is not a draft. A draft is a page on its way to being published; every page starts as one and publishing is what ends it. A private page is going nowhere — the publish guard is permanent.

It is not a page that has only reached your preview site. That page is live somewhere: it is built, deployed and one promotion away from production. A page that is only on your preview site is a different thing entirely; see Preview Site vs Live Site.

It is not access control for a group. There is no share-with list, nothing to add someone to, and no way to make a second person an exception. The test is a single field — did you create this page — and a byline does not defeat it: giving someone author or contributor credit grants access to a page they can already see, not visibility into someone else’s private one. Authors and Contributors covers what a byline does and does not reach.

StateWho can see it in the CMSCan it be published?Where it is set
PrivateOnly the member who created it, whatever anyone’s roleNeverprivate: true on the API call that creates the page; no CMS control
DraftEveryone whose role or override lets them read the pageYes — publishing is what ends the draftAutomatically; every page is created as a version 1 draft
ScheduledEveryone whose role or override lets them read the pageYes, and it publishes itself at the chosen timeThe Publish control in the page editor, with a date
DeletedNobody, unless a list explicitly asks for deleted pagesNo — the next deployment removes it from the site insteadDeleting the page in the CMS; the record is kept, with a deletion timestamp
ESC