Custom pages
Author standalone HTML and JavaScript, preview drafts and publish at exact portal paths.
A custom page is a complete HTML document with inline CSS and JavaScript. It has no forced Octocom navigation, footer or React wrapper. Use it for a contact form, support landing page or your own article interface. The customer portal must be enabled; the built-in help center is optional.
Draft, preview and published versions
In Customer portal → Custom pages, create a page with a title, URL path and
HTML. The title identifies the page in management; set the browser title inside
your HTML's <title> element.
| Action | Effect |
|---|---|
| Save draft | Persists the draft HTML and asset references. The previously published version stays live. |
| Preview | Creates a temporary link to the latest saved draft without publishing it. Save your edits first. |
| Publish | Copies the saved draft HTML and asset references to the published version together. |
| Unpublish | Removes the published version but keeps the draft. |
| Delete | Permanently removes both versions. Uploaded assets are not deleted. |
Draft and published content are stored separately. There is no full revision history or automatic rollback to older publications. Save your current published HTML separately if you will need to restore it later.
Preview links last 30 minutes and include a __portal_preview bearer token.
Anyone with the link can view the draft. Creating a new link revokes the previous
one; publishing, unpublishing or deleting also revokes it. A valid link shows the
latest saved draft rather than a frozen revision. Preview can show a custom draft
even when the built-in help center takes precedence at its public path.
Page changes take effect without a Cloudflare Worker deployment. See the MCP authoring workflow to create pages through your AI agent.
Paths and precedence
Pages match exact paths such as /, /returns or /custom/contact. A path is
unique within a business. Query strings do not select a different page; trailing
slashes are normalized and paths are case-sensitive.
Use ASCII letters, numbers, hyphens and underscores, with dots within path
segments. Paths are limited to 512 characters. Encoded paths, dot segments and
duplicate slashes are rejected. The first segments /api, /assets, /_portal,
/index.html and /favicon.ico are reserved, including their descendants.
Public document routing follows this order:
- A disabled or unknown portal returns 404.
- When Help center is enabled,
/,/article/<id>and/category/<id>use the built-in pages. A conflicting custom page remains stored but is shadowed. - Otherwise, a published custom page at the exact path is served.
- An unmatched path returns 404.
Unpublishing does not redirect visitors. The path returns to its built-in behavior if applicable, otherwise 404. There are no wildcard routes, dynamic templates or redirects in custom-page management. To change an existing page's path, save a page at the new path and unpublish or delete the old one.
Code and integrations
HTML is limited to 512 KiB of UTF-8. Keep CSS and JavaScript inline; upload images, fonts and PDF downloads as portal assets. For a custom article UI, use the public article APIs. For form submissions, see the Contact form API. Server-side integration logic can use custom HTTP endpoints.
Custom HTML executes only in the visitor's browser. It is served with an HTTP
CSP sandbox: inline scripts, forms, modals, popups and downloads are allowed,
but cookies, local storage, service workers and other same-origin privileges
are unavailable. Popups inherit the sandbox, and pages cannot be embedded in
iframes. External APIs must support the sandbox's opaque (null) origin for
browser fetches. Use credentials: "omit" when calling public article APIs.
Published HTML and its referenced assets are public. Keep credentials and private
data out of them; perform authenticated integration work on the server. Portal
documents currently include noindex, nofollow headers.