Summary

Allow multiple related content-type schemas to be organized within a single API folder, enabling logical grouping of related entities and cleaner project structure. I spent a long time doing this and not understanding why it didnt work, before being told i could grouo the controllers etc but not the schemas.

Motivation

Current Problem

In Strapi 5, each content-type requires its own API folder:

src/api/

├── forum/

├── forum-thread/

├── forum-reply/

├── forum-moderator/

├── forum-subscription/

├── forum-thread-subscription/

├── forum-notification/

└── forum-badge/

For projects with related entities (forums, e-commerce, multi-tenant systems), this creates:

many folders for a single feature domain (forums)

Cluttered admin menu with many similar entries

Poor developer experience when navigating the codebase

Difficult to understand relationships between entities

Proposed Solution

Allow multiple content-type schemas within one API folder:

src/api/forum/

├── content-types/

│ ├── forum/

│ │ └── schema.json → creates 'forums' table

│ ├── thread/

│ │ └── schema.json → creates 'threads' table

│ ├── reply/

│ │ └── schema.json → creates 'replies' table

│ ├── moderator/

│ │ └── schema.json → creates 'moderators' table

│ └── subscription/

│ └── schema.json → creates 'subscriptions' table

├── controllers/

│ ├── forum.js

│ ├── thread.js

│ ├── reply.js

│ └── moderator.js

├── routes/

│ ├── forum.js → /api/forum

│ ├── thread.js → /api/forum/threads

│ ├── reply.js → /api/forum/replies

│ └── moderator.js → /api/forum/moderators

└── services/

Benefits

Logical Grouping: Related entities organized together

Cleaner Admin Menu: Hierarchical navigation (Forum → Threads, Moderators, etc.)

Better DX: Easier to understand domain boundaries

Scalability: Large projects can organize dozens of content-types

Backward Compatible: Existing single content-type per folder still works

Technical Implementation

Each schema would still:

Create its own database table

Have independent CRUD operations

Maintain separate permissions

Generate its own API endpoints

The change is purely organizational - the content-type loader would:

Scan for multiple schema.json files within content-types/ subdirectories

Register each as a separate content-type

Optionally group them in the admin UI under a parent category

Use Cases

Forums: threads, replies, subscriptions, moderators, badges

E-commerce: products, variants, reviews, inventory, shipping

Multi-tenant: tenants, users, roles, permissions, settings

CMS: pages, sections, blocks, menus, redirects

LMS: courses, lessons, quizzes, enrollments, certificates

Related Issues & History

#12863 (Closed in v4 - revisit for v5?)

#2548 "Group content type" (2018)

#12674 Documentation issues with grouped APIs

This feature was previously rejected for Strapi v4, but with Strapi 5's architectural changes maybe it's worth reconsidering.

Why This Matters for Strapi 5

Strapi 5 represents a major evolution. Competitors like Contentful (spaces/environments) and Sanity (schema grouping) handle content organization better. As Strapi scales to larger projects, hierarchical organization becomes essential for:

Enterprise adoption

Developer productivity

Maintainable codebases

Alternative Considered

Current workaround is hiding collections via pluginOptions.content-manager.visible: false, but this:

Confuses other developers ("where's the schema?")

Doesn't solve file structure clutter

Loses admin UI benefits