Discussion on potential unexpected costs of using Sanity CMS due to API usage.

12 replies
Last updated: Mar 31, 2021
i’m evaluating CMSs for a project and i like the look of sanity but am a bit wary of the pricing.
specifically, i’ve seen various discussions in here about people unexpectedly burning through all their API usage due to e.g. the studio making lots of API calls when editing, and when i checked the stats for my test account a while ago they were definitely much closer to the usage limit than i would expect, given the small amount of testing i had done

i know its tricky as every site is different, but was wondering if anyone could say whether they were surprised by the costs of sanity compared to what they expected? basically i am comparing to fixed price solutions like Storyblok and Dato, but its hard to advise the client without really understanding how much usage editing specifically will generate
AI Update

I completely understand your concern about Sanity's usage-based pricing versus fixed-price alternatives. This is a really common question, and you're smart to investigate before committing a client to the platform.

The Reality of Studio Editing and API Usage

First, the good news: Studio editing is rarely the main cost driver in Sanity projects. The Studio does make API calls when editing - it uses listen queries for real-time collaborative updates and sends mutations when saving - but in practice, these editing operations typically represent a small fraction of total API usage unless you have dozens of editors working constantly.

Where Usage Actually Comes From

The surprise costs people encounter usually come from:

  1. Frontend queries not using the API CDN - This is the critical piece. The API CDN provides unlimited rate for cached content. If your public website queries use useCdn: true, that traffic won't count against your API request limits.

  2. Poorly optimized queries - Inefficient GROQ queries running too frequently on your frontend

  3. Webhooks or automation - If these create loops or run excessively, they can consume API requests quickly

Understanding Sanity's Pricing Structure

According to the current pricing page, the Growth Plan is $15 per user/month and includes features like private datasets, AI Assist, Content Releases, and pay-as-you-go for higher usage. There's also an "Increased Quota" add-on for $299/month that extends limits to 50k documents, 5M API CDN requests, 1M API requests, 500GB bandwidth, and 500GB assets.

The Free plan has much tighter limits, which is probably why your test account usage surprised you. The Free plan is really only suitable for very light testing or hobby projects.

Comparing to Fixed-Price Solutions

Versus Storyblok and Dato's fixed pricing:

Sanity's advantages:

  • No artificial limits on content types, locales, or schema complexity
  • The API CDN means properly cached frontend queries essentially don't count
  • You only pay for actual usage beyond base limits
  • Much more flexibility in how you structure content

The tradeoff:

  • Less predictable costs if you don't implement caching properly
  • Requires monitoring, especially during initial launch
  • Need to be more technical about optimization

Practical Recommendations for Your Client

  1. Budget for the Growth plan - The Free plan isn't realistic for production. Growth plan gives you the features you'll need.

  2. Implement proper caching from day one - Use useCdn: true for all public-facing queries. This is absolutely critical and will keep the vast majority of your traffic off the metered API requests.

  3. Monitor during soft launch - Set up usage monitoring in Sanity Manage and watch patterns during a soft launch period.

  4. Optimize queries - Use GROQ projections to fetch only the data you need. Avoid overfetching.

  5. Take advantage of the Growth Plan trial - New projects get a free trial of Growth Plan features, which gives you access to all the features without automatic charges so you can test realistic usage.

Real-World Usage Patterns

From what I've seen in the community:

  • Studio editing typically accounts for a small percentage of total API usage
  • A properly optimized production site with good caching often stays well within plan limits
  • Problems arise when developers don't implement the API CDN properly or have inefficient queries

Bottom Line

Sanity's costs are very reasonable if you implement caching correctly. For most projects with proper optimization, Sanity ends up cost-competitive or cheaper than fixed-price alternatives, especially when you factor in the flexibility and lack of artificial limits.

However, you're right that it requires more technical diligence than a truly fixed-price solution. If your team isn't comfortable with that optimization work, or if cost predictability is absolutely critical, a fixed-price CMS might be safer.

The key question: Does your team have the technical expertise to implement proper caching and query optimization? If yes, Sanity is likely a great choice. If no, the usage-based pricing could be risky.

I'd recommend:

  1. Start a new test project and use the Growth plan trial (free with no automatic charges)
  2. Build a realistic prototype with proper caching (useCdn: true for public queries)
  3. Monitor actual usage patterns in Sanity Manage
  4. Extrapolate costs based on expected production traffic

This will give you much more accurate data than testing on the Free plan, and help you make a confident recommendation to your client. The trial lets you test without risk, and you'll see exactly how your actual usage patterns translate to costs before committing.

Show original thread
12 replies
When launching a new website, content editors typically create a lot of content in a short period, creating a spike in API requests. Plus I'm usually still fixing last-minute bugs, running the website locally and making additionnal requests. So the month of the launch some of my projects neared the API limit.but the following months, it flattens again.
Keep in mind that it only costs $1 per 25k additional API Requests per month.

I would rather worry about bandwith usage if your websites have a lot of images! Here it's important to take the time to optimize and lazy-load images.
yeah i thought the free limit was 10k but now i see it was 100k so i feel a bit more at ease about that
yeah, image bandwidth is definitely another factor but i find that easier to estimate as i can look at current usage on the existing site
also paying for more image traffic is usually fine as it means the site is being visited more 🙂 whereas paying for more edit traffic is a harder concept to sell to the client
true
i guess it’s probably possible to proxy the images yourself if you are so inclined - personally i think its probably easier to just pay for the bandwidth
thanks for the advice!
To add some context: We're planning to move most of the studio activity to websockets and look at other ways of decreasing its usage. We don't want people to refrain from using the studio because worrying about API costs.
ah that’s good to know, thanks
user Y
!
i guess ultimately i really like Sanity as an option but would hate to push it to the client and then find we are paying hundreds a month to run it (they are a small business)… the API usage thing is my only real concern in that regard so if its something you are looking to address that is great 👍
Yeah, I don't think you should have to worry too much about it
that’s good to know, thank you 🙂

Sanity – Build the way you think, not the way your CMS thinks

Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.

Was this answer helpful?