Getting Started

Start with one small, complete flow#

Contoprix lets editors manage structured content while your application decides how that content looks and behaves. The easiest way to learn it is to make one published item appear on one frontend route.

This guide is written for both developers and editors. You do not need to learn every part of the platform before getting value from it.

The simple mental model#

Editor in Contoprix Admin
        |
        | creates a model, saves an entry, then publishes it
        v
Published delivery API
        |
        | authenticated with a delivery key
        v
Contoprix SDK in your server-side application
        |
        | maps entry.data into UI props
        v
Your React or Next.js components
        |
        v
Visitor sees the published page

There is a separate preview path for editors. Preview can read draft content after authenticated setup; the normal delivery API is for published content only. Keeping those paths separate is what prevents an unfinished edit from appearing on the public site.

The five things to know#

A content type describes what data exists. A frontend component decides how to render it. That boundary is intentional: editors can change text and images without changing code, and developers can improve design without changing editorial data.

What your frontend actually receives#

The SDK returns a content entry with metadata at the top level and the fields created in the CMS under data.

{
  id: "7f4d...",
  contentTypeCode: "article",
  languageCode: "en",
  slug: "hello-contoprix",
  publishedAt: "2026-08-22T09:30:00Z",
  data: {
    title: "Hello, Contoprix",
    summary: "Our first published article."
  }
}

That means this is the safe pattern:

const entry = await client.content.getBySlug("article", "hello-contoprix");
const data = entry.data as { title?: string; summary?: string };

console.log(data.title);

Do not assume entry.title exists. title is a field chosen by your own content model, so it lives in entry.data.

A beginner-friendly first goal#

Build this small flow before expanding the model:

1. Create or select a website and make sure it has a default language, such as en.
2. Create an article content type with title, slug, and summary fields.
3. Create one English Article entry and publish it.
4. Create a delivery key with read access for that website.
5. Use the SDK from a server component or server-side module to fetch the entry by slug.
6. Render the values in a small React component.

Once that works, the rest of the platform becomes easier to reason about: relations link records, media fields resolve assets, pages arrange blocks, and localization supplies a separate entry for another language.

Choose the right starting path#

A sensible project structure#

Keep Contoprix requests and data mapping away from presentational components. In a Next.js app, a small structure like this is enough:

src/
  lib/
    contoprix/
      client.ts       # one configured server-side client
      articles.ts     # fetch and map Article entries
  components/
    ArticleCard.tsx   # receives normal UI props
  app/
    blog/[slug]/page.tsx

The articles.ts module should turn a flexible CMS response into the small, predictable props your UI needs. That gives optional CMS fields a clear fallback and keeps unknown data casts out of JSX.

What comes next#

After the first request succeeds, work through these in order:

1. Install the packages and configure local environment variables.
2. Create your first project using the Article example.
3. Configure the SDK once, then reuse the client.
4. Model richer content with relations, media, and localization.
5. Use the Visual Builder when editors need to compose whole pages from reusable blocks.