Choose this path when a separate application will render content. The content model and authoring workflow are the same as the Razor path; delivery replaces server-side templates.
Start the CMS host
Complete the installation and first-account steps in Build with Razor. You still need a .NET host and a database. Set this host configuration:
{
"Cendia": {
"EnableRendering": false
}
}
This disables website page rendering. The CMS stays at /cms, and content remains available
through enabled delivery endpoints. A Razor template is not required for delivery.
Model and publish an article
Use the Article model in the Razor path, or your own namespaced PageType with a required
heading. Build and restart the CMS host, create the article, and publish it. Configure a website
with its start page, language and hostname under Settings > Websites.
Checkpoint: a published article exists at a known path and culture, for example
en-US and articles/hello. Use your actual culture and path in the requests below. The request
hostname selects the website; a different hostname may select a different website in the same app.
Retrieve published content
The delivery API returns published content only:
curl -i "https://YOUR-CMS-HOST/api/en-US/pages/articles/hello"
If the website requires a delivery key, send the X-Cendia-Api-Key header with a key configured
for that website. A delivery key identifies a caller and its limits; it does not grant access to
drafts or replace content permissions. Store server-side credentials outside your frontend bundle.
Checkpoint: the response identifies your content and includes its published heading. A missing page, wrong site/language or unpublished content can produce a missing result. Inspect the HTTP status and body before changing the frontend.
Choose REST or GraphQL
Use the Delivery API for path-based reads and paged queries. Use GraphQL when a client needs a selected set of fields and related content in one query. Both follow the same publication and permission rules.
Build your frontend's presentation using the returned fields. For a content zone, map each block's content type to a frontend component. Decide deliberately how to render authored rich text and which markup your application accepts. Handle missing and nullable fields.
Connect preview deliberately
Public delivery must stay separate from editor preview. Preview endpoints can expose drafts and release content and require a valid CMS session or preview token. See the preview examples in GraphQL before connecting an editor preview to a separate frontend. Do not place preview tokens in public pages or caches.
For browser-to-CMS requests on another origin, configure the deployment's CORS policy for your actual frontend origin. CORS is not an authentication mechanism. A server-to-server frontend can avoid browser cross-origin requests and keep its credentials on the server.
Verify publication and caching
Fetch the article signed out. Edit it without publishing and fetch again: public delivery must still return the published content. Publish the change and check when the frontend updates. If your frontend caches responses or generates pages ahead of time, define a refresh strategy; CMS publication does not automatically invalidate every external cache. Use Webhooks where your integration needs publication events.
Outcome: your own frontend renders published CMS content and has an explicit plan for preview, missing content, credentials and cache refresh.
Deploy both applications
Deploy the CMS host and the frontend with their own settings. Cendia hosting manages the .NET CMS application; confirm the deployment arrangement for your separate frontend. Follow Hosting for environment and promotion behavior.