Entry Models
An entry model defines the schema for structured content that is not directly routable. Entries don't have URLs — they exist to hold reusable data that pages and other entries reference. When you need shared content that appears in multiple places across your site, or global data like site settings and navigation, you model it as an entry.
This page covers how entry models work, the different ways entries are referenced and reused, admin-only entries for site-wide settings, and how to decide between entries and pages.
What Is an Entry Model
An entry model is a content type definition where each instance is a standalone piece of structured data without its own URL. This is what distinguishes entries from pages — pages are routable and produce URLs, while entries are the supporting data layer that pages draw from.
When you create an entry model, you configure two things:
A handle — A unique identifier for the entry model, used to retrieve entries through the content API and to reference them in templates. The handle is how your code and templates address this entry type.
Fields — The data structure for the entry's content. Entry fields work the same way as page fields — text, images, groups, collections, and references to other entries are all available.
The result is a reusable data structure that can be referenced from anywhere. An "Author" entry model might define fields for name, bio, headshot, and social links. A "Site Settings" entry model might define fields for logo, company name, footer text, and social media URLs. These entries are created once and referenced wherever they're needed.
Entries as Reusable Data
The core purpose of entries is content reuse. Instead of duplicating the same information across multiple pages, you store it in one place and reference it.
Consider a blog with ten authors. Without entries, you'd add author name, bio, and headshot fields directly to the blog post page model. Every time an author's bio changes, you'd need to update it on every post they wrote. With an Author entry model, each author exists as a single entry. Blog posts reference the author entry, and changes to an author's bio propagate everywhere that entry is referenced.
This pattern applies broadly. Team members referenced on both an "About" page and individual case study pages. Categories shared across blog posts and product pages. Testimonials that appear on the homepage and a dedicated reviews page. Any time the same content appears in more than one place, entries keep it centralized.
Entry Collections
An entry model can produce a single entry or a collection of entries. The distinction depends on the nature of the content.
Single entries — Some entry models represent one-of-a-kind data. A "Header" entry holds your site's navigation links. A "Footer" entry holds your footer columns and copyright text. A "Site Settings" entry holds your logo, tagline, and global metadata. These models produce exactly one entry because there's only one header, one footer, one set of site settings.
Entry collections — Other entry models represent a category of content with multiple instances. An "Author" model produces one entry per author. A "Category" model produces one entry per category. A "Team Member" model produces one entry per person. Editors create as many entries as needed, and each entry is available for referencing from pages or other entries.
The model itself doesn't require explicit configuration to be a single or collection — this is determined by how many instances you create. However, admin-only entries (covered below) are typically used for single-instance models where you want to restrict creation.
Referencing Entries
Entries become useful when other content references them. SleekCMS provides reference fields that create relationships between content, and these relationships come in two forms.
One-to-One References
A one-to-one reference field links a page or entry to a single entry of a specific type. A blog post referencing its author is a one-to-one relationship — each post has one author.
When an editor fills in a one-to-one reference field, they see a dropdown of available entries from the referenced model. They select one, and the relationship is established. In the API response, the referenced entry's data is included inline, so your frontend code has immediate access to the full author object without a separate API call.
One-to-Many References
A one-to-many reference field links a page or entry to multiple entries of a specific type. A blog post referencing its categories is a one-to-many relationship — each post can belong to several categories.
Editors select multiple entries from the available options, and all selected entries appear in the API response as an array. This is how you model tags, categories, related products, contributor lists, or any relationship where one piece of content connects to many entries.
Reference Patterns
References are the connective tissue of your content architecture. A few common patterns:
Author attribution — A page collection (blog posts, case studies) references an Author entry model. Each post links to one author. The author's name, bio, and photo are maintained in one place and appear consistently across all their posts.
Taxonomy and categorization — A page collection references a Category or Tag entry model through a one-to-many field. Editors assign categories when creating content. Your frontend uses these references to build category pages, filter interfaces, or related content suggestions.
Shared components — An entry model stores content for a reusable element — a promotional banner, a featured testimonial, an announcement bar. Multiple pages reference the same entry, and updating the entry updates it everywhere.
Cross-referencing entries — Entries can reference other entries, not just pages. A "Team Member" entry might reference a "Department" entry. A "Product" entry might reference a "Brand" entry. This lets you build normalized data structures where relationships are explicit and content is never duplicated.
Admin-Only Entries
Entry models can be configured as admin-only, which restricts them to a single entry instance that only administrators can manage. This is the mechanism for global site settings — content that affects the entire site but shouldn't be duplicated or freely created by content editors.
Common admin-only entries include:
Navigation — The site's main navigation links, structured as a collection of menu items with labels, URLs, and optional nested items.
Footer — Footer columns, copyright text, social media links, and legal page references.
Site settings — Company name, logo, tagline, default metadata, analytics IDs, and other configuration that applies globally.
Feature flags — Toggles that control whether certain sections or features appear on the site, managed by administrators without code changes.
Admin-only entries appear in a dedicated section of the admin interface rather than in the general content list. This separation keeps the editing experience clean — content editors see the content they manage, while site-wide settings live in their own space.
In templates and API responses, admin-only entries are accessed through the getEntry() method by handle, just like regular entries. The admin-only distinction affects who can edit them and where they appear in the interface, not how they're consumed.
// Admin-only entries are accessed the same way as regular entries
const header = client.getEntry('header');
const footer = client.getEntry('footer');
const settings = client.getEntry('site-settings');
When to Use Entry vs Page
The distinction between entries and pages is about routability. If the content needs its own URL — a page someone navigates to directly — it's a page. If the content exists to support other content or to store shared data, it's an entry.
A few cases that can seem ambiguous:
Team members — If each team member has their own profile page with a URL (/team/jane-doe), model them as a page collection. If team members only appear as cards on an "About" page or as author bylines on blog posts, model them as an entry collection.
Categories — If each category has a dedicated landing page showing all posts in that category (/blog/category/design), you need a page for that. But the category data itself — name, description, icon — is still best modeled as an entry that both the category page and the blog posts reference. You can use both: an entry model for the category data and a page model for the category landing page that references the entry.
Testimonials — If testimonials are sprinkled across various pages and don't need their own URLs, they're entries. If you want a dedicated /testimonials page, that's a page — but the individual testimonials can still be entries that the page references.
The general rule: start with entries for any content that will be referenced from multiple places. Promote to pages when the content needs its own route.
| Content | Model Type | Reason |
|---|---|---|
| Blog author | Entry | Referenced by posts, no own URL needed |
| Blog post | Page (collection) | Has its own URL |
| Navigation links | Entry (admin-only) | Global data, no URL |
| Product category | Entry | Shared taxonomy, referenced by products |
| Category landing page | Page (collection) | Needs its own URL to list products |
| Site footer | Entry (admin-only) | Global layout data |
| Team member profiles | Depends | Entry if referenced only; page if individually routable |
Entry Models and the Site Builder
If you're using the integrated site builder, entry models can be bound to EJS templates just like page and block models. An entry's template defines how that entry renders when it's included in a page — an author card, a team member bio, a category badge.
When a page template encounters a reference to an entry, it can render the entry using the entry's own template. This keeps rendering logic modular — the author card layout is defined once in the author entry template and used consistently everywhere an author is referenced.
Entry templates are optional. If an entry model doesn't have a template, you access its field data directly in the page or block template that references it. Templates are most useful when the entry has a visual representation that should be consistent across the site.
→ Site Builder → Model Templates
Entry Models and the Content API
Through the content API, entries are retrieved by their handle using the getEntry() method. Single entries return a JSON object. Entry collections return an array of objects.
// Single entry (admin-only or single-instance)
const header = client.getEntry('header');
// { logo: { url: '...' }, links: [...] }
// Entry collection
const authors = client.getEntry('authors');
// [{ name: 'Jane', bio: '...', headshot: { url: '...' } }, ...]
// Entries referenced from pages are resolved inline
const post = client.getPage('/blog/hello-world');
// post.author → { name: 'Jane', bio: '...', headshot: { url: '...' } }
// post.categories → [{ name: 'Design', slug: 'design' }, ...]
When a page references an entry, the entry's data is resolved inline in the page's API response. You don't need to make a separate call to fetch the referenced entry — it's already embedded in the page data. This applies to both one-to-one and one-to-many references.
→ Content API → @sleekcms/client
What's Next
- Page Models — Routable content types with URL paths and slug-based collections.
- Block Models — Reusable, composable content components for dynamic page sections.
- Content Field Types — The full set of field types available in page, entry, and block models.
- Option Sets and Lists — Key-value pairs for dropdowns and centralized taxonomy.
- Content Editing — The editing experience for content creators working with entry models.