The Layer Everything Else Depends On
Zunoy's headless CMS API is schema-first. Define a content type once and a typed REST API is generated automatically, validated on write.You can tell how much thought went into a CMS by what happens when the model gets complicated. A post with a title and body is easy. A case study with a repeating results section, each result referencing a product, is where engines either hold up or start needing workarounds you'll maintain for years.
10
Field types
5
Roles with granular permissions
4
Lifecycle webhook events
1
Schema powering every surface
Schema-First, Not Shape-Guessing
Inferred structure
Frontends write defensive parsing for data that should be structured
One malformed entry can break a production page
Response shape varies entry to entry
Relationships tracked manually by ID
The API contract is enforced before content is stored
Invalid content is rejected on write, not on render
Every entry of a type returns the same shape
References are a first-class field type
Ten Field Types, Including the Hard Ones
Ten field types, covering the structures content outgrows in year two.
Plain strings, and formatted content with tables and images
Typed primitives with validation on write
References into the central Media Hub library
Controlled vocabularies, single or multi-value
Freeform structure that fits no other type
Relationships to entries of other content types
Repeating field groups — results, FAQs, feature lists
Dynamic zones holding one or many block types, nestable
THE ONES THAT MATTER
Repeaters and Blocks Are Where Models Break
A repeater handles content where the same field group repeats an arbitrary number of times. A blocks zone handles an area that can contain any of several component types in any order. Both can nest, with a depth limit keeping models comprehensible.Between them, these two types cover the structures that otherwise get forced into a rich-text field and lost as structured data. If you've ever had to represent a landing page as queryable content rather than a blob of HTML, this is the capability that determines whether you can.
Repeaters model "this section repeats N times, same fields"
Blocks model "this area holds any of these components, any order"
Nesting is supported, with a depth cap to keep models readable
Content Has a Lifecycle, Not Just a State
Entries move through draft, published, unpublished, and hidden states, and each transition dispatches a webhook. This is what makes automated static-site revalidation practical without polling or scheduled rebuilds.
Draft by default
New entries start unpublished, so work in progress never hits the live API.
Publish transitions
Four events — create, publish, unpublish, delete — each firing a webhook.
Revalidation
Publish fires, your frontend rebuilds the affected page. Nothing polls.
PERMISSIONS
Editing Content and Editing the Model Are Different Rights
Zunoy ships five roles — owner, developer, developer approver, content writer, and viewer — with granular view and edit permissions per area covering content types, entries, pages, media, forms, and branches.The separation that matters most is between changing content and changing the schema behind it. A writer should be able to publish an article without being able to delete the content type that article belongs to. Zunoy expresses that directly, as two distinct permissions held by different roles.
entries.edit and content_types.edit are separate rights
Schema changes stay with the people responsible for schema
Per-area view and edit control across six areas
Start From a Template, Not a Blank Screen
A library of built-in templates installs complete content models — a blog, a product catalog, and others — in one step, creating the required types and fields while skipping any that already exist. The underrated value is knowing what fields a well-modeled blog should have. Installing one and editing it beats modeling from scratch.
How It Works
From definition to delivery, with validation applied at the point content is written rather than when it is read.
Every Other Module Is Built on This Content Engine
The content engine isn't one module among several. It's the substrate the rest of the platform runs on.
Visual Page Builder
Blocks and pages use the same schema the API serves
Localization
Locale values overlay the same fields on the same entries
Environments
Types, entries, and pages branch together as a unit
AI Studio
Generation operates on defined fields, not free text
Media Hub
Media fields reference the central asset library
MCP Server
Types and entries exposed as agent-callable tools
Common Questions
What is a headless CMS API?
What field types does Zunoy support?
Ten types — text, richtext, number, boolean, date, media, select, json, reference, repeater, and blocks — covering simple values, relationships, and complex nested structures like repeating groups and dynamic component zones.
Can Zunoy model nested and repeating content?
Yes. Repeater fields handle repeating groups of fields, and block zones hold one or many block types in any order. Both support nesting, with a depth limit that keeps content models comprehensible rather than infinitely recursive.
Can content entries reference each other?
Yes. The reference field type creates relationships across content types, so an article can reference its author or a case study can reference the products it features, resolved server-side rather than reconstructed by the client.
Does the API separate draft and published content?
Yes. Entries carry a status covering draft, published, unpublished, and hidden, so work in progress never appears on the live content API until it is explicitly published.
Model Your Content Like It Has to Last
Because it does. The model you define in week one is the one your team lives with for years.
CMS
A headless CMS to model content and ship it anywhere.
Operational
Integrations
Mail Us
support@zunoy.com
Copyright © 2026 - Mentcube Innovations Pvt Ltd.. All Rights Reserved.
v0.1.101 · Built Aug 12, 2026, 4:13 AM