---
title: Introduction
description: What ZevContent is, what it is not, and the one decision you make before anything else.
---

ZevContent is a **headless content backend**. You describe the shape of your
content, people who are not developers fill it in, and your frontend reads it
over a REST API.

Headless means we have no opinion about your frontend. There is no theme, no
template language and no renderer. We serve JSON, and what you build with it
is entirely yours. If you are looking for something that produces a website,
this is the wrong tool.

## The one decision: your own type, or a built-in module

Everything in ZevContent is one of two things, and knowing which you need is
most of the setup.

**Custom content types** are shapes you define. A `team-member` with a name, a
role and a photo. A `pricing-tier` with a price and a feature list. A
`homepage` singleton with a headline. You choose the fields, we store and serve
them, and the response shape follows your definition exactly.

**Built-in modules** are content types *we* define, document and maintain. There
are three: a [blog](/modules/blog), a [knowledge base](/modules/knowledge-base),
and the shared [author directory](/modules/authors) both of them credit. You
create nothing first. Every project has these endpoints from the moment it
exists, and they serve an empty list until somebody writes something.

> **INFO: Why a blog is built in and a gallery is not**
>
> A blog is not a shape, it is a **set of behaviours**: slugs that must stay
> stable, an SEO chain with fallbacks, reading time, ordered co-authors, a
> category that is a page and a tag that is not. Ten teams modelling that
> themselves would produce ten subtly broken versions of the same thing, and
> each would discover the missing parts in production.
>
> A gallery is a shape: a title and a list of images. Nothing about it needs our
> opinion, so it is a custom type, and there is a template in the dashboard to
> start from.

## What you get without asking

Because a built-in module has a schema we control, it can do work for you that a
custom type cannot:

- **SEO arrives resolved.** `seo.title` falls back to the article title,
  `seo.description` to the excerpt and then to the opening of the body,
  `seo.og_image` to the featured image. You render what you are given. See
  [SEO](/concepts/seo).
- **References arrive as objects.** A listing carries the resolved author and
  category, not `author_id` and `category_id`, so twenty article cards cost one
  request rather than twenty-one.
- **Derived figures are computed.** `reading_time_minutes`, `word_count`, and
  the knowledge base's `freshness` verdict.

## What it is not

- **It is not a page builder.** There are no layouts, sections or blocks that
  render themselves.
- **It does not host your images.** Media goes to *your* object storage, and
  bytes never pass through us. See [Media](/concepts/media).
- **It is not a database.** The query surface is deliberately bounded: filters
  are ANDed, there is no OR and no nesting. A query that needs those is
  describing a report, not a page.

## Where to go next

If you have a key, the fastest path is the [quickstart](/guide/quickstart):
three curl commands and you have read real content.

If you are an AI agent, or you are pointing one at this API, read
[For AI agents](/guide/agents) first. The short version: call
`/v1/introspection` before you read anything here, because it describes *your*
project rather than the product in general.