---
title: "Serve Multiple Payload CMS Collections from One Route"
slug: "payload-cms-multiple-collections-one-route"
published: "2025-12-18"
updated: "2025-12-21"
categories:
  - "Payload"
tags:
  - "Payload multiple collections route"
  - "Next.js route disambiguation"
  - "payload cms page vs post route"
  - "multi-tenant route disambiguation"
  - "payload route handler orchestration"
llm-intent: "how-to"
audience-level: "intermediate"
llm-purpose: "Payload CMS multiple collections: disambiguate slugs and serve events + workshops from one /events/[slug] route using route detection and direct…"
llm-prereqs:
  - "Payload CMS"
  - "Next.js"
  - "TypeScript"
  - "React"
---

**Summary Triples**
- (Serve Multiple Payload CMS Collections from One Route, expresses-intent, how-to)
- (Serve Multiple Payload CMS Collections from One Route, covers-topic, Payload multiple collections route)
- (Serve Multiple Payload CMS Collections from One Route, provides-guidance-for, Payload CMS multiple collections: disambiguate slugs and serve events + workshops from one /events/[slug] route using route detection and direct…)

### {GOAL}
Payload CMS multiple collections: disambiguate slugs and serve events + workshops from one /events/[slug] route using route detection and direct…

### {PREREQS}
- Payload CMS
- Next.js
- TypeScript
- React

### {STEPS}
1. Add direct collection verifiers
2. Implement route detection functions
3. Add handler verification logic
4. Orchestrate handlers in page
5. Test and extend for more collections

<!-- llm:goal="Payload CMS multiple collections: disambiguate slugs and serve events + workshops from one /events/[slug] route using route detection and direct…" -->
<!-- llm:prereq="Payload CMS" -->
<!-- llm:prereq="Next.js" -->
<!-- llm:prereq="TypeScript" -->
<!-- llm:prereq="React" -->

# Serve Multiple Payload CMS Collections from One Route
> Payload CMS multiple collections: disambiguate slugs and serve events + workshops from one /events/[slug] route using route detection and direct…
Matija Žiberna · 2025-12-18

> **Note:** While this guide uses tenant context (common in multi-tenant apps), the pattern applies to any scenario where multiple content types share a URL path. If you're building a multi-tenant app and need this pattern, ensure you have the [basic multi-tenant setup](/blog/production-ready-multi-tenant-nextjs-payload) working first.

I was building a client's event management site when I hit an interesting architectural challenge. They had two distinct content types—public events and interactive workshops—with completely different data structures and admin interfaces. The business requirement was straightforward: both should be accessible from `/events/[slug]` for SEO and user experience reasons. Technically, putting them on separate routes like `/events` and `/workshops` would've been cleaner, but business needs don't always align with technical elegance.

After implementing a working solution, I realized this pattern solves a broader problem that many developers face when building Payload CMS sites with complex content hierarchies. This guide walks you through the exact implementation I developed, covering route detection, collection verification, and handler orchestration. By the end, you'll understand how to let business requirements drive your architecture while keeping the technical implementation clean.

... (rest of the content) ...

## Step 1: Create Collection Verification Functions

... (rest of the content from local backup) ...

## Step 4: Orchestrate Handlers in the Main Page Component

... (rest of the content from local backup) ...

## Conclusion

This pattern solves a real problem that many CMS projects face: business requirements often dictate unified URLs for better SEO and user experience, but data structure differences demand separate collections. Rather than forcing content into unnatural structures or creating awkward URLs, you can embrace both requirements by building smart disambiguation logic.

The key takeaway is this: let route detection be permissive (accept multiple possibilities), let database verification be authoritative (the true arbiter of which collection owns a slug), and let handler orchestration be sequential (first match wins). Together, these three layers create a clean, maintainable system that handles complex real-world scenarios.

You now have a reusable pattern that works for any number of collections on the same path. Whether you're dealing with events and workshops, products and content products, or blog posts and news articles, the approach remains the same: detect permissively, verify authoritatively, orchestrate sequentially.

Let me know in the comments if you have questions about adapting this pattern to your specific needs, and subscribe for more practical development guides.

Thanks, Matija