# CMS boundaries ### About this export | Field | Value | | --- | --- | | **content_type** | lesson | | **platform** | contentstack-academy | | **source_url** | https://www.contentstack.com/academy/courses/cms-developer-foundations/cms-boundaries | | **course_slug** | cms-developer-foundations | | **lesson_slug** | cms-boundaries | | **markdown_file_url** | /academy/md/courses/cms-developer-foundations/cms-boundaries.md | | **generated_at** | 2026-08-27T06:59:28.933Z | > Part of **[CMS Developer Foundations](https://www.contentstack.com/academy/courses/cms-developer-foundations)** on Contentstack Academy. **Academy MD v3** — structured for retrieval; no quiz or assessment keys. #### Lesson text # CMS boundaries > **TL;DR** > > * Contentstack is the system of record for editorial content, not a general-purpose database, application server, or hosting platform > * If content teams create and maintain the data through editorial workflows, it belongs in the CMS. If it is system-generated or transactional, it belongs elsewhere > * The CMS does not handle routing, user authentication, e-commerce transactions, or scheduled jobs > * Clear boundaries keep the CMS performant and make team responsibilities unambiguous The fastest way to misuse a headless CMS is to expect it to do things it was never designed to do. Developers new to Contentstack frequently ask it to handle routing, run application logic, manage user sessions, or store transactional data. These expectations come from experience with monolithic platforms where the CMS was the application. In a headless architecture, the CMS is one component in a larger system. Understanding where its responsibilities end is just as important as understanding what it provides. ## The boundary principle Contentstack is the system of record for content. That single sentence defines the boundary. Content means structured editorial material - articles, product descriptions, page layouts, banners, navigation structures, configuration blocks, media assets. Content is what editors create, review, approve, and publish through editorial workflows. Everything that is not content - routing logic, rendering, user authentication, shopping cart state, search indexing, payment processing, personalization algorithms, scheduled jobs - lives outside the CMS. These concerns belong to your frontend application, your backend services, your third-party integrations, or your infrastructure layer. This boundary is not a limitation of the product. It is a design principle that keeps the CMS focused, reliable, and performant. A system that tries to do everything does nothing well. By constraining its scope to content operations, Contentstack can optimize for the things that matter in that domain: structured storage, editorial workflows, multi-environment publishing, API performance, asset delivery, and content governance. ## What Contentstack does ### Stores and structures content Contentstack's core function is storing structured content defined by content types you design. Each content type is a schema, each entry is an instance of that schema, and the API returns entries as structured JSON. The content model is yours to design - Contentstack provides the field types, validation options, and schema management tools, but you decide the structure. Content is stored with full version history. Every save creates a new version, and previous versions can be compared side by side or restored. This versioning applies to entries and content types alike, giving you an audit trail for both content changes and schema evolution. ### Manages content lifecycle Contentstack provides workflow management for the editorial process. You define workflow stages - Draft, In Review, Legal Review, Approved, Published - and assign roles to each stage. Entries move through workflow stages as they progress toward publication. Workflow stages can restrict who can edit or publish, require approvals before advancement, and trigger actions (such as notifications) on stage transitions. Publishing itself is environment-aware. An entry can be published to "staging" without being published to "production." This gives editorial teams a controlled promotion path: create content, review it in a staging environment, then publish to production when approved. ### Serves content via APIs Contentstack exposes content through multiple API surfaces: * **Content Delivery API (REST)**: a CDN-backed REST API optimized for high-volume read access to published content. This is the primary API your frontend applications use. * **Content Delivery API (GraphQL)**: a GraphQL endpoint that allows frontend applications to query exactly the fields they need, reducing payload size and over-fetching. * **Content Management API (REST)**: a REST API for creating, updating, deleting, and managing content, content types, assets, environments, workflows, and other administrative operations. This API is used by back-office tools, migration scripts, and automation workflows - not by frontend applications at runtime. Each API surface has its own token model and its own performance characteristics. The delivery APIs are designed for speed and scale. The management API is designed for operational control and auditability. ### Hosts and transforms assets Images, documents, videos, and other files are stored in Contentstack's asset repository with CDN-backed delivery. For images, Contentstack provides an on-the-fly transformation pipeline: resize, crop, format conversion (WebP, AVIF), quality adjustment, and other manipulations via URL parameters. This eliminates the need for a separate image processing service for standard transformation needs. Assets are managed within the CMS UI with folder organization, metadata, tagging, and search. They can be referenced from entries through File fields or embedded in rich text content. ### Provides webhooks for event-driven architecture Contentstack fires webhooks on content lifecycle events: entry created, entry updated, entry published, entry unpublished, content type modified, asset uploaded, and many others. Webhooks deliver HTTP POST requests to URLs you configure, allowing external systems to react to content changes in real time. This is the primary mechanism for connecting Contentstack to the rest of your architecture. When an entry is published, a webhook can trigger a static site rebuild, invalidate a CDN cache, update a search index, notify a Slack channel, or synchronize content to an external system. Webhooks are the event bridge between the CMS and everything else. ### Offers Live Preview and Visual Builder Live Preview enables editors to see draft content rendered in the actual frontend application before publishing. Visual Builder extends this by allowing editors to interact with the rendered page and edit content fields directly in context. Both capabilities require frontend implementation (covered in Course 4), but the infrastructure - preview tokens, preview API endpoints, the Live Preview SDK, the Visual Builder framework - is provided by Contentstack. These tools bridge the gap between structured content management and visual editing. They give editors confidence in their content without requiring the CMS to own the rendering layer. ### Supports content branches Branches allow parallel development of content type schemas. You can create a branch, modify content types on that branch, test the changes, and merge them back to the main branch when ready. This prevents schema changes from disrupting editors who are actively creating content on the main branch. Branches apply to content types and global fields - the structural definitions. They provide a safety mechanism for schema evolution that is analogous to feature branches in code version control. ### Provides workflow management Beyond the basic workflow stages described above, Contentstack's workflow system supports publish rules (restricting which roles can publish to which environments), workflow-level notifications, and integration with Automation Hub for more complex workflow automation. Workflows can be assigned per content type, giving you granular control over the editorial process for different kinds of content. ## What Contentstack does not do Understanding these boundaries prevents architectural mistakes that are expensive to correct. ### Does not host your website Contentstack is not a web hosting platform. Your frontend application - whether it is a Next.js site, an Astro project, a React SPA, or a mobile app - runs on infrastructure you choose and manage. Contentstack serves content to that application via API. The application renders it. Contentstack does offer **Launch** as a separate product for hosting frontend applications, but Launch is a distinct service with its own configuration and deployment model. The core CMS platform does not include hosting. ### Does not run server-side application logic There is no server-side scripting environment inside Contentstack. You cannot write custom backend code that executes within the CMS. If you need server-side logic - data transformation, aggregation, API orchestration, business rule enforcement - that logic runs in your own backend services, serverless functions, or middleware layer. Contentstack provides **Automation Hub** for event-driven automations (triggered by content lifecycle events), and **Marketplace apps** can extend the CMS UI and behavior. But these are defined extensions, not a general-purpose application runtime. ### Does not manage end-user authentication Contentstack manages access for CMS users - editors, developers, administrators who log into the Contentstack platform. It does not manage authentication for the end users of your website or application. If your site has login functionality, user accounts, role-based access, or gated content, that authentication system lives outside Contentstack. You might use Auth0, Clerk, Firebase Auth, Cognito, or a custom solution. The CMS has no concept of your website's visitors. ### Does not handle e-commerce transactions Contentstack can store product content - descriptions, images, specifications, marketing copy. But it does not process transactions, manage inventory, handle pricing rules, calculate tax, or process payments. E-commerce functionality belongs to dedicated platforms like Shopify, commercetools, BigCommerce, or Stripe. Contentstack integrates with these systems as a content source - you manage product content in the CMS and transactional data in the commerce platform. ### Does not serve as a general-purpose database Contentstack is a content management system, not a database. It is optimized for editorial content that moves through a create-review-publish lifecycle. It is not designed for storing large volumes of transactional data, user-generated content at scale, analytics events, session data, or high-frequency write operations. The Content Delivery API has rate limits designed for content retrieval patterns, not database query patterns. The Content Management API has rate limits designed for editorial and administrative operations, not bulk data processing. If you need to store and query large datasets, use a database. Use Contentstack for the content that editors manage. ### Does not run scheduled jobs Contentstack supports scheduled publishing - you can schedule an entry to be published at a future date and time. But it does not provide a general-purpose job scheduler. If you need to run periodic tasks - data synchronization, report generation, cache warming, content auditing - those jobs run on your own infrastructure or through services like AWS Lambda with EventBridge, Google Cloud Scheduler, or GitHub Actions. **Automation Hub** handles event-driven automations triggered by content actions, but it is not a cron replacement for arbitrary scheduled workloads. ### Does not manage URL routing or redirects The CMS stores content. It does not decide what URLs that content appears at. URL structure, routing logic, redirect rules, canonical URLs, and sitemap generation are all responsibilities of your frontend application or your hosting infrastructure. You might store a URL slug as a field on a content type, but the CMS does not enforce or manage those URLs as routes. ## Why these boundaries matter Clear boundaries make the CMS more reliable and your architecture more maintainable. When the CMS focuses on content, it can optimize for content operations: fast API delivery, efficient publishing, robust editorial workflows, reliable asset management. When you push non-content concerns into the CMS - using it as a database, expecting it to run application logic, treating it as a hosting platform - you work against the system's design and create fragile integrations. The boundary also clarifies team responsibilities. Content editors own the content in the CMS. Developers own the frontend application and the integration layer. Infrastructure teams own hosting, deployment, and external services. When boundaries are clear, each team can work independently within their domain. For integration patterns with external systems - commerce platforms, search engines, personalization tools, analytics services - see Course 7. The key principle from this lesson is that Contentstack is the system of record for content, and everything else connects to it rather than running inside it. ## Common mistakes > **Common Pitfall** > > Storing non-content data (feature flags, app config, transactional records) in content types clutters the editorial interface and pushes the CMS beyond its design. Use environment variables or dedicated configuration services instead. ### Mistake 1: Storing non-content data in content types Using Contentstack to store configuration data, application state, user preferences, or transactional records stretches the system beyond its design. Content types are for editorial content. Application configuration belongs in environment variables, configuration services, or feature flag systems. Transactional data belongs in databases. ### Mistake 2: Expecting the CMS to manage URL routing Creating a content type with a URL field does not mean the CMS manages routing. The URL field stores a string value. Your frontend application reads that value and uses it to construct routes. Redirects, URL validation, canonical URL logic, and sitemap generation are all frontend or infrastructure responsibilities. ### Mistake 3: Building application logic into webhook handlers that should live in dedicated services Webhooks are excellent for event notification - triggering a build, invalidating a cache, sending a notification. They are not a substitute for a backend service. Complex business logic triggered by content events should live in a proper service layer with error handling, retry logic, logging, and monitoring - not in a webhook endpoint that processes the event inline. #### Key takeaways - Connect **CMS boundaries** back to your stack configuration before moving to the next module. - Capture one concrete artifact (screenshot, Postman call, or code snippet) that proves the step works in your environment. - Re-read the delivery versus management boundary for anything you changed in the entry model. ## Supplement for indexing ### Content summary CMS boundaries. CMS boundaries TL;DR Contentstack is the system of record for editorial content, not a general-purpose database, application server, or hosting platform If content teams create and maintain the data through editorial workflows, it belongs in the CMS. If it is system-generated or transactional, it belongs elsewhere The CMS does not handle routing, user authentication, e-commerce transactions, or scheduled jobs Clear boundaries keep the CMS performant and make team responsibilities unambiguous The fastest way to misuse a headless CMS is to expect it to do things it was never designed to do. Developers new to Contentstack frequently ask it to handle routing, run application logic, manage user s ### Retrieval tags - CMS - boundaries - cms-developer-foundations - lesson 04 - CMS boundaries - cms-developer-foundations lesson ### Indexing notes Index this lesson as a primary chunk tagged with lesson_id "04" and topics: [CMS, boundaries]. Parent course slug: cms-developer-foundations. Use asset_references URLs as thumbnail hints in search results when present. Never surface LMS quiz content or assessment answers from this file. ### Asset references _No image or video thumbnail URLs were extracted._ ### External links | Label | URL | | --- | --- | | Contentstack Academy home | `https://www.contentstack.com/academy/` | | Training instance setup | `https://www.contentstack.com/academy/training-instance` | | Academy playground (GitHub) | `https://github.com/contentstack/contentstack-academy-playground` | | Contentstack documentation | `https://www.contentstack.com/docs/` |