Activity Messenger Help Center

Website API: publish pages

Use the Website API to create, replace, or remove content pages on an existing Activity Messenger website. Each page change is staged as an immutable revision. The public website changes only after you review and publish that revision. For the general organization API, see the API reference. For uploads, reusable sections, and redirects, see Website API: assets, shared sections and redirects.

Connect and discover the website

Use the API introduction for authentication, headers, pagination, rate limits, and error handling. All paths below are relative to https://activitymessenger.com/api/v1/organization/{organization}/websites/{website} unless stated otherwise.

The base path is /v1/organization/{organization}/websites. GET on that path lists website IDs. Choose one and append /{website} for the other calls. IDs are numeric resource IDs, not slugs or domains.

  • GET /: website identity, theme, default locale, and enabled locales.
  • GET /component-schema: current schema_version, supported layout templates and slots, content formats, locales, and validation rules.
  • GET /pages: page IDs, localized titles/slugs, navigation and visibility fields, and edit_version.
  • GET /pages/{page}: a page snapshot and its current checksum.
  • GET /page-keys/{key}: the page and latest publication for your stable external key; both are null for an unused key.

Check many page keys at once

Use GET /page-keys?keys=key-one,key-two when you need publication state for multiple stable page keys without fetching the full snapshot for each one. This batch endpoint returns a compact result for each key; use GET /page-keys/{key} when you need the individual page's full description and snapshot.

For example, append this query to the website path:

GET /page-keys?keys=welcome,registration-guide,contact
Accept: application/json

The response is an object whose pages property is keyed by page key. Each entry includes the page_key, a compact page value with its numeric id and edit_version, and last_publication status:

{
  "pages": {
    "welcome": {
      "page_key": "welcome",
      "page": {"id": 321, "edit_version": 4},
      "last_publication": {
        "id": 845,
        "page_key": "welcome",
        "status": "published",
        "published_at": "2026-09-27T12:00:00.000000Z"
      }
    },
    "registration-guide": {
      "page_key": "registration-guide",
      "page": null,
      "last_publication": null
    }
  }
}

The example is abbreviated: last_publication includes the publication status fields returned by the API. A key with no published publication has null values for both page and last_publication. Keys are comma-separated; surrounding whitespace is trimmed, empty values are ignored, and duplicate keys are returned once. Supply between 1 and 250 distinct keys. Each key must start with a lowercase letter or digit and contain only lowercase letters, digits, hyphens, or underscores; invalid or excessive input returns HTTP 422. The encoded keys query value is limited to 8,000 characters.

Stage and publish a page

  1. Discover the site's enabled locales and component-schema.
  2. For an existing page, read its current checksum. Use "missing" only for a new page key.
  3. Stage the entire page document with POST /pages for a new keyed page, PUT /pages/{page}/document to replace an existing page, or POST /revisions for either upsert or delete. DELETE /pages/{page} stages a deletion; it does not delete immediately.
  4. Inspect the HTTP 201 response or GET /revisions/{revision}. Review before_snapshot, the submitted document, compiled native components, content_checksum, and status. The compiled payload is for review, not a public preview URL.
  5. Publish exactly that revision with POST /revisions/{revision}/publish and {"content_checksum":"<64-character checksum from staging>"}. A successful response includes the page ID, final published_checksum, status, and publication time.

This English-only example is a body for POST /revisions. Replace the IDs and content for your website. A bilingual website requires both en and fr in every localized object, including each block's content; a French-only website requires fr.

{
  "page_key": "getting-started",
  "operation": "upsert",
  "expected_checksum": "missing",
  "document": {
    "locales": {
      "en": {"title": "Getting started", "slug": "guides/getting-started", "description": "Learn the essentials."}
    },
    "published": true,
    "show_in_nav": false,
    "nav_parent_id": null,
    "order": 10,
    "is_crawler_visible": true,
    "assets": [],
    "sections": [{
      "template": "single-column",
      "blocks": [{"slot": "main", "format": "markdown", "content": {"en": "# Getting started\\n\\nWelcome."}}]
    }]
  }
}

Use a stable page_key of at most 100 lowercase letters, digits, hyphens, or underscores. An optional source_commit is a 40–64 character hexadecimal commit ID. POST /pages sets operation=upsert and identifies an existing page by its key. PUT /pages/{page}/document binds the revision to that page; use it when adopting a page under a new external key. DELETE /pages/{page} needs the key and current checksum without a document.

Page document and update rules

Version 1 supports single-column (main), two-columns and two-columns-wide-right (left, right), and three-columns-wide-center (left, center, right). Blocks use format: markdown or format: html and compile to editable native rich-text blocks. Markdown strips raw HTML and unsafe links; HTML goes through the rich-text sanitizer. Tables and code blocks are supported. anchor_id can identify a section. Use GET /component-schema for the current contract before generating a document.

A replacement replaces all sections and blocks; their numeric IDs may change. It updates localized title, slug, description, navigation, publication, and indexing fields, while preserving unrelated pages and site settings. Shared-section placements on that page are removed unless the document explicitly includes the desired sidebar reference. Inspect before_snapshot before adopting or replacing an editor-created page. The homepage and 404 page are protected. Move navigation children before deleting their parent. Deletion is soft and separately published; this API has no restore endpoint. Media are not deleted with a page.

The same validated staging request is idempotent, and publishing the same revision again returns its prior result. For a new change, fetch the latest checksum and stage a new revision. A deleted key remains bound to its original page. Publishing rechecks the baseline, ownership, assets, locale configuration, slugs, and navigation parent; HTTP 409 means the reviewed state changed and you should fetch and stage again. Document requests are limited to 2 MB. See the introduction for common error responses.

Limits include 100 sections, 50 blocks per section, 200 assets, 200,000 characters per localized block, and at most three slash-separated slug segments. The website's own visibility and password settings still apply. A page with published: false remains unavailable publicly after publication of its revision.

The API manages content pages on existing websites. It does not create websites or domains, expose every builder template, change the shared theme, or provide a separate public preview site.