Custom frontends

Fetch published content#

Use a public CMS base URL in the frontend configuration. Do not bundle an administrator password, a session cookie or provider credentials.

const cmsBase = 'https://cms.example.test';
const endpoint = new URL('/api/v1/pages', cmsBase);
endpoint.searchParams.set('locale', 'en-AT');
endpoint.searchParams.set('limit', '20');
const response = await fetch(endpoint);
if (!response.ok) throw new Error('Content unavailable');
const { items, pagination } = await response.json();

Rendering safely#

Use text rendering for titles and descriptions. If you display the html field, use an audited sanitiser and a suitable Content Security Policy in your frontend as well. Resolve relative images against the CMS origin, and handle loading, empty and error states. Pair languages with translationKey and preserve public routes deliberately. The API delivers HTML, not a framework component tree. Starter CSS and CMS font settings do not automatically become React or Svelte styling.

Included local example#

With the CMS running on port 8020, start the independent example in a second terminal:

php -S 127.0.0.1:5173 -t examples/frontend

Set the exact API origin to match that frontend. The example deliberately uses its own design and safe text rendering. Do not interpret its presence as an SDK, a hosted deployment or a stable authoring API.

Booking and forms#

Link appointment actions back to the CMS host's /booking/ route. Cross-origin booking writes are intentionally unsupported. The current contact module is content and links, not a configurable submission form builder.