Per-seat, per-API-call, per-locale: the three pricing models bleeding mid-market budgets

When a mid-market organisation signs a SaaS contract, it signs against the number on the pricing page. What it pays twelve months later is often two to three times that number. The gap is not buried in fine print. It comes from three specific pricing mechanics that vendors design for predictable revenue growth and that buyers consistently underestimate at the time of purchase.

Why list price is the wrong number to evaluate

The list price is the least important number in a SaaS contract. More important are three structural questions that determine what the contract will actually cost as the organisation grows: How does cost scale with team size, usage and geographic expansion?

Per-seat pricing answers the first, API-call metering the second, and per-locale pricing the third. Most mid-market organisations evaluate the list price and miss the scaling questions entirely.

The problem is information asymmetry. The vendor knows exactly how these models will compound at the buyer’s scale and growth rate, the buyer rarely does.

Pricing model 1: per-seat

How it works

Per-seat pricing charges a fixed fee per user account per month. The fee applies to every person who needs access to the platform: content editors, developers, reviewers, approvers, stakeholders with read access, and administrators. Seats are tracked at the user level, not the usage level. A seat used once a month costs the same as one used every day.

Where the cost builds

Team size is the most predictable growth vector. A content platform signed for a marketing team of eight will serve a team of twenty in two years if the company is growing. Seat count grows with headcount, not with the value extracted from the platform. A platform costing $40,000 per year for eight editors costs $100,000 per year for twenty, and the platform itself has not changed.

Platforms that prove useful get adopted by more teams. A CMS signed for marketing becomes useful to product, sales, localisation, and compliance. Each adoption wave adds seats. Organisations that sign for their initial team rarely model the full eventual seat count.

Then there is the stakeholder access problem. Enterprise platforms often require seats for people who are not active editors: executives who need read access for approval, legal reviewers who need access once per quarter, external agencies needing temporary campaign access. These low-utilisation seats cost the same as full-time editorial seats.

The Contentful example

Contentful’s pricing structure is representative of the per-seat model at scale. Usage overages, additional environments, and premium support can add 20 to 50% to base subscription costs depending on growth patterns, according to Vendr’s analysis of anonymised Contentful transactions. Organisations that budget for the base plan and grow into a larger team without modelling seat escalation consistently find the contract value is materially higher at first renewal than at signing.

Reducing seat costs

Auditing which seats are active and reducing count at renewal often yields a meaningful reduction. The more durable fix is migrating to a platform with uncapped seats. Payload, as an open-source self-hosted alternative, has no per-seat cost on the core platform. Sanity’s Enterprise tier is negotiated and can include unlimited seats. For organisations with large or fast-growing editorial teams, the seat cost alone frequently justifies the migration calculation.

Pricing model 2: per-API-call

How API metering works

API-call pricing charges for requests made to the platform’s delivery API. Every time a web page loads content from the CMS, every time a mobile app fetches a product description, every time an internal tool queries the knowledge base, that request is an API call. The platform counts them and charges for volume.

The model looks manageable at small scale. Most plans include a base allocation that appears generous in the context of the initial deployment. It stops looking generous when the site grows, when a mobile app is added, or when the content platform is integrated with additional surfaces.

The overage triggers

Traffic growth is the most visible driver. A site serving 50,000 monthly visitors at contract signing may serve 300,000 two years later. Each page view generates multiple API calls: one for the page content, additional calls for navigation, related content, and dynamic components. Traffic growth that marketing celebrates translates directly to API overage charges that finance investigates.

The more common driver of unexpected API usage is adding delivery surfaces. A platform serving one website now also serves a React Native mobile app. Both make API calls. Native apps tend to be chattier than websites by design, pre-fetching content, refreshing on app open, syncing in the background. The mobile app was not in scope when the original API call estimate was made.

CDN bypass compounds this further. Platforms like Contentful cache API responses at the CDN layer; cached responses do not count against API limits, uncached responses do. Organisations with high content update frequency, or whose content changes frequently enough to keep the CDN cache cold, burn through API allocations faster than traffic volume alone would suggest. A content team publishing multiple times per day is effectively working against its own CDN cache.

The numbers

78% of IT leaders surveyed reported unexpected charges tied to consumption-based or AI pricing models, according to Zylo’s 2026 SaaS Management Index. The API call model is the most common source.

Contentful’s usage limits documentation shows how the overage model works in practice: overages are charged monthly in arrears at rates defined in the service order. In early 2025, Contentful introduced a soft limits period for its Functions feature where overages would not be charged during a grace period. That decision was itself an acknowledgement that consumption-based pricing produces unexpected charges that buyers find difficult to anticipate.

Controlling API costs

Three interventions reduce API call costs: optimising CDN caching to maximise the cache hit rate and minimise origin calls, rightsizing the API call allocation at renewal based on actual measured usage, or migrating to a platform where delivery is not metered. Self-hosted headless CMSes like Payload and Strapi have no API call limits. The delivery layer is owned by the organisation and served from its own infrastructure. Hosting costs scale linearly and predictably with usage; vendor metering does not.

Pricing model 3: per-locale

How locale pricing works

Per-locale pricing charges for each language or regional variant of content. The mechanics vary by vendor. Some platforms include a base number of locales (Contentful’s Team tier includes 3) and charge for additional locales as add-ons. Others factor locale count into API call allocations, where more locales means more API calls for the same number of page views. Some platforms price their enterprise tier partly on locale count, making international expansion a direct contract renegotiation trigger.

Where it gets expensive

A platform signed for English and Spanish becomes a platform for six locales when the company enters three additional markets. The locale add-on cost appears at the next billing cycle or triggers a plan upgrade. The business decision to enter a new market, made by the growth team, creates a technology cost that was not budgeted by finance.

Per-locale pricing is not just a cost line. More locales mean more editorial review surfaces, more workflow steps, and more places for content to be in an inconsistent state. The platform cost of adding a locale is the smallest component of the true cost. Translator coordination, locale-specific QA, and locale-specific approval chains are larger, and rarely modelled at the time of platform selection.

There is also a content model constraint to watch. Contentful caps content types at 100 per environment on its standard plans. An organisation with 6 locales that models localisation as separate content items consumes that content type budget at 6x the rate of a monolingual implementation. The locale pricing problem and the content type limit problem interact in a way that accelerates both.

How it plays out

An organisation that starts with 2 locales on Contentful’s Team tier (3 locales included) is within the base allocation. Adding 4 more locales to serve European markets triggers locale add-on charges. Those same 4 new locales each require their own editorial workflow states, their own API call usage, and their own content type variants if the content model was not designed for localisation from the start. The cost of international expansion lands simultaneously as a platform cost, an API cost, and a content type cost.

Payload’s locale plugin supports unlimited locales with no pricing impact. Locale is a configuration decision, not a billing line item. For organisations where global expansion is on the roadmap, the per-locale pricing model is worth modelling explicitly before signing any contract that meters it.

How the three models compound together

The most expensive scenario is not any single pricing model but the combination of all three at scale.

Consider a mid-market B2B SaaS company that signs a Contentful contract for a marketing site with 10 editors, serving one market, with a baseline traffic profile.

Year 1: 10 editors, 2 locales, 500,000 API calls per month.

Year 3: The company has grown. The marketing team has 25 editors. Product and localisation teams also need access: 40 seats total. The site now serves 4 markets. Traffic has grown from 500,000 to 2,000,000 monthly API calls. A React Native app added in year 2 contributes another 800,000 API calls per month.

The year 3 platform cost is the result of three independent multipliers operating simultaneously: seat count growth (4x), locale count growth (2x), and API call growth (5.6x combined web and mobile). The contract at renewal reflects all three, and the negotiation happens when the finance team is already committed to the platform and switching cost is high.

This trajectory is why organisations consistently underestimate their content platform costs by a factor of two to three over a three-year period.

What organisations that have figured this out do differently

Model the three-year cost at time of selection. Project seat count from hiring plans rather than current team size, traffic from growth targets rather than current volume, and locale count from market expansion plans rather than current operations. The three-year model is not difficult to build, it does not get built because the people selecting the platform (usually engineering or marketing) are not the people who will feel the renewal invoice (usually the CFO).

Negotiate caps on each pricing dimension. Per-seat contracts can negotiate seat price caps at fixed counts. API call contracts can negotiate CDN-inclusive plans that eliminate origin call counting. locale contracts can negotiate flat-rate access above a threshold. These negotiations are most effective at initial contract signing, when the vendor has acquisition motivation, and least effective at renewal, when switching cost has accumulated.

Evaluate self-hosted alternatives for long-term cost. The three-year TCO of Payload (zero licensing, infrastructure cost only) versus Contentful (per-seat, per-API-call, per-locale) is not competitive at small scale. Contentful’s SaaS convenience is worth the premium for small teams and simple deployments. At mid-market scale with 30 or more editors, 4 or more locales, and mobile app delivery, the compounding effect of all three pricing models frequently produces a substantial three-year TCO gap in favour of self-hosted alternatives. The tradeoff is operational ownership: the engineering team takes on infrastructure, upgrades, and monitoring. At the scale where compounding pricing applies, the financial case is significant.

If your organisation is approaching a CMS renewal and has not modelled the three-year cost across all three pricing dimensions, book a call.

---

FAQ

1. What is per-seat pricing in SaaS?

   Per-seat pricing charges a fixed fee per user account per month, regardless of how much each user actually uses the platform. It is the most common pricing model for enterprise SaaS and the most predictable at small team sizes. It becomes the most significant cost driver as team size grows, because seat count increases with headcount rather than with the value extracted from the platform.

2. What is consumption-based pricing for a CMS?

   Consumption-based pricing charges for the volume of API calls, requests, or data transfer made to the platform. For a headless CMS, this typically means counting the number of times the delivery API is called: every page view, every app session, every content refresh. The model is designed to align cost with usage. In practice it creates cost unpredictability as traffic grows and new delivery surfaces such as mobile apps and partner portals are added.

3. What is per-locale pricing and how does it affect enterprise CMS cost?

   Per-locale pricing charges for each language or regional variant of content managed in the platform. Organisations that expand internationally add locales, and each locale may trigger additional charges for the locale add-on, additional API call allocations, and additional content type usage if the content model was built for localisation through content duplication rather than field-level localisation. Per-locale pricing makes international expansion a direct billing event.

4. What does "API call overage" mean in a Contentful contract?

   An API call overage occurs when the number of API requests made to the Contentful delivery API in a month exceeds the allocation included in the plan or contract. Overages are charged monthly in arrears at a per-call rate defined in the service order. CDN-cached responses typically do not count against the allocation; uncached responses do. Organisations with high content update frequency, aggressive cache invalidation, or multiple delivery surfaces are most exposed to overage charges.

5. How do you calculate the true three-year cost of a headless CMS?

   Three-year CMS cost = (Annual base subscription × 3) + (Seat overage charges based on projected team growth) + (API call overage charges based on projected traffic and surface growth) + (Locale add-on charges based on market expansion plans) + (Implementation cost, amortised) + (Annual maintenance engineering cost × 3). The most common modelling error is using current values rather than projected values for seats, API calls, and locales. The compounding effect of growth across all three dimensions is what produces the two to three times gap between initial expectations and actual cost.

6. What alternatives exist to per-seat, per-API-call, per-locale pricing?

   Open-source self-hosted CMS platforms like Payload and Strapi have no per-seat, per-API-call, or per-locale charges on the core platform. The cost is infrastructure: hosting, database, CDN delivery, all of which scale linearly and predictably with usage. Sanity's Enterprise tier is negotiated and can include unlimited seats. The tradeoff for self-hosted alternatives is operational ownership, with the engineering team responsible for infrastructure, upgrades, and monitoring rather than a vendor.

---

Sources

• Vendr: Contentful Software Pricing and Plans 2026
• Contentful: Usage Limits Documentation
• Zylo: 2026 SaaS Management Index
• SaaStr: The Great SaaS Price Surge of 2025
• Net Solutions: Contentful Pricing Guide 2026