Strapi Content Types — Collection Types, Single Types, and Components

In this tutorial, you will learn the three content modeling primitives in Strapi — collection types, single types, and components — and understand when to use each one for building flexible content architectures.

What You'll Learn

• The difference between collection types and single types with real-world examples
• How components enable reusable field groups across multiple content types
• When to use each type and the trade-offs involved
• How API endpoints differ between collection types and single types
• How to create and organize components for maximum reusability
• Best practices for content modeling in Strapi

Why It Matters

Content modeling is the foundation of any Strapi project. Choosing the right structure for your content determines how easy it is to manage entries, how flexible your API is, and how much work you create for your frontend team. A well-modeled content architecture saves hundreds of hours of development time and prevents content management headaches.

Real-World Use

A travel booking platform needs to model Destinations (hundreds of entries, each with name, description, images), Site Settings (one entry for site-wide configuration like contact email and social links), and Addresses (reused across Destinations, Hotels, and Offices). Collection types handle the many Destinations. Single types handle the one Site Settings. Components handle the reusable Address block.

Learning Path

flowchart LR
  A["Content Types
-- You are here"]:::current
  A --> B["Fields & Attributes"]
  B --> C["Relations"]
  C --> D["Components & Dynamic Zones"]
  D --> E["Content Lifecycle"]
  E --> F["REST API"]
  F --> G["API Parameters"]

  classDef current fill:#4945ff,color:#fff,stroke-width:2px

Collection Types

A collection type represents content that has multiple entries. Each entry is a record with the same set of fields. This is what most people think of as a database table.

Examples of collection types:

• Articles (hundreds of news articles)
• Products (thousands of catalog items)
• Users (millions of registered users)
• Recipes (dozens or hundreds of recipes)

Collection types generate plural API endpoints:

/api/articles    — GET, POST
/api/articles/:id — GET, PUT, DELETE

/api/products    — GET, POST
/api/products/:id — GET, PUT, DELETE

Think of a collection type like a filing cabinet. The cabinet is the type. Each folder inside is one entry. When you need to store multiple items of the same kind, use a collection type.

Single Types

A single type represents content that has exactly one entry. You do not create new entries — you edit the existing one. Single types are perfect for content that exists once and is accessed globally.

Examples of single types:

• Homepage (hero banner, featured content, SEO metadata)
• Site Settings (site name, logo, contact email, social links)
• About Page (company story, team introduction)
• Footer Configuration (copyright text, link columns)

Single types generate singular API endpoints:

/api/homepage    — GET, PUT
/api/site-settings — GET, PUT

You might be wondering why you would not just use a collection type with one entry. The difference is user experience. Single types remove the list view entirely. The editor opens the single type and edits it directly, without needing to find it in a list first. This is much cleaner for content that only exists once.

Components

Components are reusable field groups. You define a set of fields once and reuse them across multiple content types. This follows the DRY (Don't Repeat Yourself) principle and ensures consistency.

Examples of components:

• SEO Metadata (title, description, og-image, keywords)
• Address (street, city, country, postal code, coordinates)
• Social Link (platform, URL, icon)
• Media Gallery (title, image, caption, order)

Components live in their own section of the Content-Type Builder. You create a component first, then add it as a field to any content type.

// Component schema example: seo.json
// src/components/common/seo.json
{
  "collectionName": "components_common_seos",
  "info": {
    "displayName": "SEO",
    "icon": "search",
    "description": "SEO metadata component"
  },
  "attributes": {
    "title": {
      "type": "string",
      "required": true,
      "maxLength": 60
    },
    "description": {
      "type": "text",
      "required": true,
      "maxLength": 160
    },
    "og_image": {
      "type": "media",
      "allowedTypes": ["images"],
      "multiple": false
    }
  }
}

Components can be:

• Single (not repeatable) — Think of this like a single address block. One component instance per parent.
• Repeatable — Think of this like a list of social links. Multiple instances, each with its own data.

When to Use Each Type

A common mistake is using a collection type where a single type is appropriate, or vice versa. Here is the rule: if you can imagine having more than one, use a collection type. If there can only ever be one, use a single type.

How API Endpoints Differ

// Collection Type API
// Plural endpoint with entry IDs
GET /api/articles
// Response: { data: [{ id: 1, attributes: {...} }, ...], meta: {...} }

GET /api/articles/1
// Response: { data: { id: 1, attributes: {...} } }

// Single Type API
// Singular endpoint, no ID
GET /api/homepage
// Response: { data: { id: 1, attributes: {...} } }

The single type response does not include pagination meta because there is only one entry.

Content Modeling Best Practices

1. Plan before building. Sketch your content model on paper or in a diagram tool before opening the Content-Type Builder. Identify every content type, its fields, and its relationships.

2. Use components for repeated patterns. If you see the same group of fields in multiple content types, extract it into a component. This keeps schemas clean and changes propagate automatically.

3. Keep single types truly single. Do not use single types for content that might need multiple instances later. Changing a single type to a collection type requires migrating data.

4. Name content types for API consumers. The singular and plural names become API endpoints. Name them thoughtfully. "Recipe" becomes /api/recipes. "Product Category" becomes /api/product-categories.

5. Avoid over-normalization. Components add complexity. Use them for field groups that are genuinely shared across types, not for grouping fields that belong to only one type.

Common Mistakes

1. Using collection types for content that should be a single type. Creating a "Site Settings" collection type means editors see a list view with one entry, which is confusing. Use single types for unique content.

2. Not using components for shared field groups. Defining the same SEO fields across five content types creates maintenance overhead. When you need to add a new SEO field, you must update all five types. Use components.

3. Making components too large. A component with 20 fields is harder to reuse than several smaller components. Break large components into focused sub-components.

4. Ignoring the API endpoint names. Strapi automatically generates endpoint names from your content type names. A typo in the plural name creates confusing API URLs. Verify the generated names before saving.

5. Creating too many content types too early. Start with the minimum viable content model and add types as needed. Over-engineering the content architecture before understanding the requirements leads to restructuring later.

Practice Questions

1. What is the difference between a collection type and a single type? Answer: A collection type has multiple entries accessed through plural endpoints (/api/articles). A single type has exactly one entry accessed through a singular endpoint (/api/homepage).

2. When would you create a component instead of inlining fields? Answer: When the same group of fields appears in multiple content types. For example, an "Address" component used by both a "Restaurant" type and a "User" type.

3. How do API responses differ between collection types and single types? Answer: Collection type responses include a data array and meta with pagination. Single type responses include a single data object without pagination.

4. Challenge: Model the content architecture for a university website. Identify at least 5 collection types, 2 single types, and 3 components. Write the purpose of each type and sketch the fields it needs. Explain why you chose each type.

FAQ

Mini Project

Your task: Design and implement a complete content model for a restaurant directory.

1. Create a collection type "Restaurant" with fields: name, description (richtext), cuisine_type (enumeration: italian, mexican, japanese, indian, american), price_range (enumeration: $, $$, $$$), rating (decimal, 0-5).
2. Create a single type "Site Settings" with fields: site_name, support_email, about_text.
3. Create a component "Address" with fields: street, city, state, postal_code, country, google_maps_url.
4. Add the Address component to the Restaurant type as a repeatable component called "locations" (some restaurants have multiple branches).
5. Create a component "Operating Hours" with fields: day_of_week (enumeration), open_time (time), close_time (time). Add it to Restaurant.
6. Add sample data for at least 3 restaurants and test the API endpoints.

What's Next

Now that you understand content types, proceed to Fields & Attributes to explore every field type Strapi offers — from strings and numbers to JSON and media. After that, learn how to connect content types through Relations.

Related lessons:

• WordPress Custom Post Types — Compare with Strapi collection types
• GraphQL — How content types become Graphql types
• Node.js — How Strapi stores content types