Next.js CMS

A headless CMS integration designed for Next.js App Router.

Contoprix provides published page and content delivery, React rendering primitives, and Next.js server helpers for routing, preview, and cache revalidation without moving CMS credentials into browser code.

The current @contoprix/next package targets Next.js 16 and React 19, with a dedicated server entry point for App Router integrations.

Integration Model

Contoprix supplies content. Next.js owns the application.

The CMS, delivery boundary, Server Components, and browser experience each have a clear role.

Contoprix

Models, drafts, pages, media, and published versions

→

Delivery

@contoprix/next/server, REST, or GraphQL

→

Next.js

App Router, Server Components, routes, and caching

→

User

HTML and interactive React experiences

This is a framework-specific implementation of the broader headless CMS architecture.

Verified SDK Surface

The integration uses real Contoprix packages and server helpers

These capabilities are present in the current SDK and reference Next.js application, rather than being placeholder integration claims.

Server-side delivery helpers

getContoprixPage and createContoprixClient read server-only configuration and call published delivery from App Router server code.

Catch-all page routing

Map a Next.js [...slug] route to the same full public path used by Contoprix page delivery, including nested routes.

React component rendering

Register your React components and render ordered CMS page blocks while keeping their implementation in the frontend repository.

Signed publish revalidation

handleContoprixWebhook verifies the Contoprix signature and revalidates published page paths and content tags.

Install the SDK packages Configure server credentials Review the SDK API

App Router Page Delivery

Fetch a published page in a Server Component

The current SDK exports getContoprixPage from @contoprix/next/server. It reads server environment configuration and resolves a published page by its public path.

In a production route, distinguish a real delivery 404 from authentication, configuration, and network failures. Convert only the missing-page case to notFound() and let other failures reach normal application monitoring.

Read the routing guide Follow the complete App Router tutorial

app/[...slug]/page.tsxReal SDK contract

import { getContoprixPage } from "@contoprix/next/server";

import { ContoprixRenderer } from "@/contoprix/ContoprixRenderer";

export const revalidate = 60;

export default async function CmsPage({
  params,
}: {
  params: Promise<{ slug: string[] }>;
}) {
  const { slug } = await params;
  const page = await getContoprixPage({
    slug: `/${slug.join("/")}`,
    languageCode: "en",
  });

  return <ContoprixRenderer page={page} />;
}

app/api/contoprix/webhook/route.ts

import { handleContoprixWebhook } from "@contoprix/next/server";

export async function POST(request: Request) {
  return handleContoprixWebhook(request, {
    secret: process.env.CONTOPRIX_WEBHOOK_SECRET!,
  });
}

Published Content Freshness

Revalidate when publication changes

A time-based revalidation interval is a useful safety net. For faster updates, the SDK's webhook handler verifies the X-Contoprix-Signature HMAC before revalidating page paths and Contoprix cache tags.

Saving a draft does not update public delivery. Cache refresh belongs to the publish path, after editors have previewed and approved the change.

Read publishing and revalidation guidance

Preview, Locale, and Cache Boundaries

Keep editorial and public delivery paths separate

The framework helpers support the boundaries a production Next.js site needs around drafts, credentials, locale selection, and cache freshness.

Separate preview delivery

getContoprixPreviewPage reads a draft by page ID through a protected preview route rather than normal published delivery.

Private credentials

Delivery, preview, and webhook secrets stay in server environment variables without a NEXT_PUBLIC_ prefix.

Explicit locales

Pass languageCode on page and content requests so App Router locale paths map to a published Contoprix language version.

Controlled cache refresh

Use a revalidation interval, a signed publish webhook, or both according to the freshness and resilience needs of the site.

Set up visual editing Build dynamic content routes Configure localization

REST or GraphQL

Choose delivery per screen, not per framework

Next.js can consume either interface on the server. The framework does not force the content-query style.

SDK and REST

Use getContoprixPage or createContoprixClient for common page, content, navigation, media, and search delivery.

GraphQL

Use the tenant-specific GraphQL delivery endpoint when a Server Component needs a precise combination of page, navigation, relation, or generated content-model fields.

Explore GraphQL CMS delivery Read the GraphQL guide

Production Checklist

A working request is only the first integration milestone

Routing, credentials, missing-content behavior, component coverage, publication, and cache invalidation should be verified together before a CMS-backed route is considered production-ready.

Keep CONTOPRIX_DELIVERY_KEY and preview credentials server-side.
Pass the full public path to getContoprixPage or pages.getBySlug().
Convert only genuine delivery 404 responses to Next.js notFound().
Register every component code used by published Visual Builder pages.
Use a signed webhook or an appropriate revalidation interval for published changes.
Publish and request the exact language code used by the frontend route.

Build with Contoprix

Continue with the real installation and App Router documentation.

Need visual page composition too? Review how the visual headless CMS workflow maps approved components into frontend rendering.

Start with the docs Start Free