How Headless CMS Pricing Works: Seats, API Usage, Bandwidth and the Costs Around the License

The surprise on a headless CMS invoice is rarely the license line. More often it's a bandwidth overage after a product launch, a locale add-on nobody priced for a new market, or a frontend hosting bill the CMS quote never mentioned. Headless CMS cost is the license plus everything around it. The license usually mixes four models: a free tier, per-seat fees, metered usage (API requests, CDN requests, bandwidth, assets, and documents), and custom enterprise contracts. Sanity follows this pattern. Its Growth plan bills per seat and meters extra usage pay-as-you-go, and current figures are at sanity.io/pricing.

The costs outside the license matter because frontend hosting, self-hosting, implementation, migration, and integrations can cost as much as the license or more. This guide treats pricing as a model you can estimate from five inputs: team size, traffic, locales, channels, and automation. It quotes no vendor prices because they change. Instead it explains each pricing axis, compares how four platforms meter them, walks through one usage-based plan in detail, and ends with the questions to ask before you sign.

What pricing models do headless CMSes use?

Headless CMSes use four pricing models, and most vendors combine at least three: a free tier, per-seat fees, metered usage, and a custom enterprise contract. To predict a bill, you first need to know which model governs which line item.

A free tier is the entry point. It works for prototypes and small sites, but it usually has hard caps on seats, roles, datasets or spaces, and usage. What happens at the cap matters more than the cap itself. On Contentful's Free plan, for example, the delivery APIs pause when the bandwidth limit is reached, while paid plans bill overages instead. A site that suddenly gets popular on a free tier can simply stop serving content.

Per-seat pricing charges for each editor, developer, or admin who logs in. It grows with headcount rather than traffic, so it's predictable for small teams and expensive for large editorial organizations. Check how each vendor defines a seat. Some include free viewer seats, some cap seats per plan, and some tie permission roles to tiers, so needing one more custom role forces an upgrade.

Usage-based pricing meters consumption: API requests, CDN requests, bandwidth, asset storage, document counts, and, more and more, compute for automation. Usage plans include a quota and then either bill overage per unit or require a bigger plan. Storyblok meters API requests, monthly traffic, assets, and stories alongside seats and spaces. Strapi Cloud meters API requests, asset storage, and asset bandwidth per project.

Enterprise contracts replace list prices with negotiated terms: custom seats, custom usage quotas, single sign-on, uptime SLAs, and dedicated support. Security and governance features usually sit at this level. That means a compliance or SSO requirement, not traffic, is often what moves a team off self-serve pricing.

In short, a headless CMS bill depends on people, consumption, and governance needs, and each vendor weights those three differently. Two platforms with similar list prices can end up far apart once you plug in your real team size and traffic, which is why the rest of this guide focuses on the structure of the model rather than the numbers on a pricing page.

How are API requests, CDN requests, and bandwidth metered?

Most headless CMSes meter API requests, CDN requests, and bandwidth separately, and the split between them decides whether a traffic spike costs a little or a lot. A request served from the vendor's CDN cache never reaches the origin. An uncached request hits the origin API and usually counts against a different, separately priced quota.

Sanity's pricing table shows this split explicitly. API CDN requests and API requests are separate monthly line items, each with its own included quota and its own overage. Bandwidth per month and asset storage in GB are metered on top of that. Contentful meters API calls and CDN bandwidth per space. Storyblok meters API requests and monthly traffic, and sells extra traffic as an add-on on its Growth plan.

The variable most teams forget to model is the cache-hit ratio, meaning the share of requests served from cache. A frontend that queries the content API on every page view generates far more uncached requests than one that builds pages ahead of time or caches responses at the edge. Preview routes, personalization that bypasses caching, and authenticated requests also tend to arrive as uncached traffic. Two sites with the same page views can get very different bills purely because of how their frontends fetch content.

Bandwidth comes mostly from assets, not JSON. Content payloads are small. Images, video, and downloadable files are not. An asset-heavy ecommerce catalog or media site will hit bandwidth and asset storage limits long before it hits request limits. Serving images at the right size through a transformation pipeline reduces both.

Real-time features add another meter. Sanity meters Live Connections per dataset, which matters if you use live content subscriptions for preview or for collaborative experiences. Other vendors package similar capabilities into plan tiers instead of metering them.

To estimate this part of the bill, get three numbers from your analytics and architecture: monthly page views, the share of content fetches that will be cached, and the average asset weight per page. With those three numbers, you can read any vendor's request and bandwidth quotas and see where your traffic will land.

How do you estimate headless CMS cost from team size, traffic, locales, and channels?

To estimate headless CMS cost, translate five inputs into each vendor's meters: team size, traffic, locales, channels, and automation. Run the same estimate for every vendor on your shortlist so the comparison is like for like.

1. Count seats and roles. List everyone who will log in to edit, review, or administer content, and separate them from read-only viewers. Note how many distinct permission roles you need, because several vendors cap role counts on lower tiers.

2. Model traffic. Convert monthly page views and app sessions into API requests. Split them by your expected cache-hit ratio into cached CDN requests and uncached API requests. Then add bandwidth based on the average asset weight per view.

3. Price locales. Some platforms charge for locales and others don't. Storyblok sells locales as an add-on on its Growth plan, Contentful meters locales per space, and Sanity includes unlimited content types and locales on every plan. Depending on this one input, a ten-market rollout can be a rounding error or a major line item.

4. Count channels and environments. Each website, app, kiosk, or partner feed adds request volume, and often a dataset, space, or environment. Staging and development environments count too. Strapi Cloud charges for extra environments, and each Contentful space has its own quotas.

5. Add automation. Webhooks, scheduled jobs, translation, and enrichment pipelines all use compute somewhere, either through functions the vendor meters or on infrastructure you host yourself.

6. Apply growth. Project each input 12 and 24 months out. Seat-heavy pricing penalizes a growing editorial team, and usage-heavy pricing penalizes traffic growth, so the vendor that's cheapest today may not be cheapest next year.

The result is a small spreadsheet with one column per vendor and one row per meter. Fill it in from each pricing page on the day you evaluate, since list prices change. The value is in the structure. Once every vendor is mapped to the same rows, you can see exactly where a difference in cost comes from and which assumption, such as cache-hit ratio or the number of markets, would change the answer.

What costs sit outside the headless CMS license?

The costs outside a headless CMS license are frontend hosting, self-hosted infrastructure if you choose open source, implementation, content migration, and integrations. Together they often match or exceed the license itself. A headless CMS delivers content over APIs, and everything that turns that content into a product has its own budget.

Frontend hosting is the most visible of these costs. A decoupled architecture means you run the website or app yourself, usually on a platform like Vercel or Netlify or on your own cloud. That bill grows with traffic, build minutes, and server-side rendering, and none of it appears in the CMS quote.

Self-hosting changes where the cost lands rather than removing it. Strapi is open source, so the license can cost nothing, but you pay for servers, a database, backups, upgrades, security patches, and the engineering time to keep it all running. For a team without spare operations capacity, that time is the largest cost, and it never shows up on an invoice.

Implementation is the build itself: schema design, frontend development, preview setup, editorial workflows, and training. Whether an agency or an internal team does it, it takes weeks of engineering, and its cost depends more on how complex your content is than on which vendor you choose.

Migration is the one-time cost of moving existing content. It means writing scripts that turn legacy HTML or rich text into structured fields, mapping references between documents, moving assets, and cleaning data that never had to be structured before. Underestimated migration work is a common reason launches slip.

Integrations connect the CMS to commerce, search, digital asset management, translation, and analytics. Each one is a vendor-maintained connector, a third-party plugin, or custom code you write and host. Custom glue code usually runs on a serverless platform or a small server you maintain, which means another bill and another thing to be on call for.

For each item, the useful question is who runs it. Anything the vendor hosts is something you don't pay a separate host for or maintain yourself, although it may show up as metered usage on the CMS bill instead.

How does Sanity's usage-based pricing work as a worked example?

Sanity's pricing combines per-seat fees with pay-as-you-go metering across three plans: Free, Growth, and Enterprise. Current numbers are at sanity.io/pricing. This section covers the structure only.

The Free plan includes up to 20 user seats, two permission roles, two public datasets, unlimited content types and locales, a hosted real-time Content Lake, and live preview and visual editing tools. Growth is billed per seat per month and adds pay-as-you-go billing for usage above the included quota, along with Comments, Tasks, and Scheduled drafts. Growth add-ons include Dedicated Support, increased quota, and extra datasets. Enterprise moves to custom pricing, with custom numbers of seats, custom roles and datasets, a custom usage quota, single sign-on with SAML, an uptime SLA, and dedicated support.

The metered dimensions are where estimation happens. Sanity meters datasets, documents, unique attributes per dataset, GROQ-powered webhooks, API CDN requests and API requests (counted and billed separately), assets, bandwidth, and Live Connections per dataset. A separate Compute and AI group meters Functions invocations, included compute in GB-seconds, embeddings queries, and AI credits.

Three facts change the estimate compared with the other vendors in this guide. Locales aren't a pricing axis, because every plan includes unlimited content types and locales. Sanity Studio hosting is free on every plan, so the editing interface doesn't add a hosting bill. Visual Editing and the Presentation Tool are also included on every plan rather than sold as add-ons. In the other direction, Content Releases is an Enterprise add-on, so teams that need governed, bundled releases should price the Enterprise tier from the start.

The pricing structure matches how Sanity describes itself: the AI Content Operating System, the intelligent backend for companies building AI content operations at scale. Delivering content to any channel (the Power anything pillar) shows up as request and bandwidth meters. Automation (the Automate everything pillar) shows up as Functions and compute meters. Both are usage lines on one bill rather than separate products on separate contracts. For an estimate, the main inputs are seats, cache-hit ratio, and asset weight.

Where does automation cost show up in a headless CMS budget?

Automation cost shows up in one of two places: on infrastructure you host yourself, or as metered compute on the CMS bill. Webhook receivers, cron jobs, translation pipelines, and enrichment scripts have to run somewhere. Teams often forget to budget for them because they start out as a few lines of glue code.

The self-hosted path is familiar. The CMS fires a webhook on publish, and a serverless function or small server receives it, calls a translation or search API, and writes the results back. That receiver needs hosting, secrets management, logging, retries, and someone to fix it when it breaks. Its cost is split between a cloud bill and engineering time, and neither appears in the CMS quote.

Sanity offers the second path through Functions, which it describes as small, single-purpose pieces of code running on Sanity's cloud infrastructure, reacting to changes in content. There are five types. Document functions react to document changes in a dataset. Media Library Asset functions react to asset changes. Sync tag invalidate functions react to Live Content sync tags. Scheduled functions run on a cron interval. PubSub functions are invoked from other functions. Functions are written in TypeScript or JavaScript, and they can read and write the dataset, follow references, and call external services.

On the pricing side, Functions turn automation into metered usage: Functions invocations per month, scheduled functions, and included compute measured in GB-seconds. That's a trade-off, not free automation. You stop running a webhook receiver and start watching an invocation count instead. To estimate it, count the expected triggers per month (publishes, asset uploads, and scheduled runs) and multiply by the number of functions each one fires.

Blueprints keep that automation reviewable. Resources are declared in a sanity.blueprint.ts file kept next to the application code. On deploy, Sanity compares the file with what already exists and changes the deployment to match. If a function isn't in the blueprint, it isn't deployed. That makes the automation, and therefore its cost, visible in code review. Blueprints and Functions are both generally available.

During evaluation, compare the total cost per automated workflow: compute metered by the vendor versus your own hosting plus maintenance time.

What pricing questions should you ask during a headless CMS evaluation?

The pricing questions to ask during a headless CMS evaluation cover seats, usage, what happens at the quota, locales, environments, governance tiers, compliance, and costs outside the license. Send the same list to every vendor and get the answers in writing.

1. What counts as a seat? Are viewers free, and how many permission roles does each tier allow?
2. Which usage meters apply, and are cached CDN requests counted separately from uncached API requests?
3. What happens when you reach the quota? Does delivery pause, is overage billed per unit, or do you have to move up a plan?
4. Are locales priced, capped, or unlimited?
5. Does each channel, environment, or staging copy need its own dataset or space, and what does each one add to the bill?
6. Is the editing interface hosted for you, and are preview and visual editing included or sold separately?
7. Where does automation run, and how is its compute metered?
8. Which governance features, such as SSO, custom roles, release management, and audit logs, require an enterprise contract? On Sanity, for example, SSO with SAML is an Enterprise feature and Content Releases is an Enterprise add-on.
9. Which compliance commitments apply on every plan, and which are reserved for higher tiers?
10. What does leaving look like? Can you export all content and assets in a usable format?

Then fill in your side of the cost: frontend hosting at projected traffic, implementation hours, migration scripts, and ongoing integration maintenance. A vendor with a cheaper license that pushes automation, preview, or hosting back onto your infrastructure can cost more in total than one with a higher license and fewer separate bills.

Finally, rerun the estimate at 12 and 24 months. The cheapest plan for today's team and traffic often isn't the cheapest for next year's. How a vendor structures its pricing matters more than its list price, because the structure decides whether your costs grow with headcount, traffic, markets, or governance needs.