Get help on Discord

High number of API requests during site migration, looking for help and guidance.

5 replies
Last updated: Feb 9, 2024
Hi all, I have been working on a site migration (around 150 pages) and it's almost ready to go live. I have noticed however that this month we've used 62,000 API requests while filling in the content and in development. I can't help but feel this is a lot considering the site is not getting any visitors yet? Can anyone help me out? I've checked all my useEffects and I don't have a rogue one anywhere. I also noticed that making a single change in the studio causes a request - I read that these don't count towards my monthly quota, but could this be the cause?
AI Update

Great question! I can see why this would be concerning during a migration. Let me clarify what's happening with your API usage.

The good news: Studio requests DO NOT count toward your API quota. According to Sanity's 2021 announcement about subscription plans, they explicitly state: "API calls from the Sanity Studio no longer count towards your usage." This was a significant change they made so the Free plan's quota goes further. This is also confirmed by Sanity team members in community discussions.

So those Studio edits you're making? They're not eating into your 62,000 requests.

Where Your API Requests Are Actually Coming From

Your 62,000 API requests are likely coming from your frontend application during development. Here are the most common culprits based on similar cases:

1. Frontend queries hitting the regular API instead of the CDN Even with useCDN: true configured, certain scenarios bypass the CDN:

  • Queries using draft/preview perspectives (only published perspective uses CDN)
  • Real-time listeners and live queries
  • Queries with fresh data requirements

2. Queries in shared components Navigation bars, footers, and layout components that query on every page load can rack up requests quickly during development. In one similar case, a loadSettings query in the navbar/footer was responsible for a disproportionate amount of API calls.

3. Cache invalidation during active development When you publish changes in Studio, your frontend cache invalidates and triggers fresh requests. During active migration work with 150 pages, this adds up.

How to Fix This

Ensure you're using the API CDN: The API CDN has 1M requests/month on Free (vs only 100k for regular API). Make sure:

  • Your production client uses apicdn.sanity.io (not api.sanity.io)
  • Queries use the published perspective when possible
  • Your client config has useCdn: true for published content

Optimize your queries:

  • Review which queries run most frequently
  • Implement proper caching in your frontend
  • For Next.js, leverage ISR/SSG to reduce runtime queries
  • Consider GROQ query optimization

Debug your usage: Check your Sanity dashboard for API usage patterns. If you need help identifying which specific queries are the culprit, Sanity support can provide that breakdown with your project ID.

Understanding Your Quotas

According to Sanity's plans documentation:

  • API requests: 100k/month (Free plan)
  • API CDN requests: 1M/month (Free plan) - 10x more!

The key insight: Most production traffic should hit the CDN, not the regular API. If 62k of your usage is going to the regular API during development, that suggests your queries aren't properly configured for CDN usage.

For a 150-page migration with active development and content editing, 62k requests isn't necessarily alarming during the build phase. But once live, ensure your queries use the CDN to access that much larger quota. If you need more after optimization, the Growth plan ($15/month) includes 1M API requests and 10M CDN requests.

Can you share more details about your build?
it uses the next personal website starter, the project id is ibl2iujd if that helps!
user M
any ideas? I don't want to launch this site if it's going to run out of requests so quickly - it already gets some decent traffic on the old wordpress build.
Hello User!Sorry for the slow response here! I will share some more insights (about bandwidth etc.) with you later.
Indeed in-studio requests do not count against bandwidth, only request being done from outside the studio are counted.

My gut feeling tells me tho, that you have either or all of these things causing in-studio requests being counted:
• Maybe You are using the front-end configured client in the studio, not the client passed down in the contexts (like the configContext or in the structure) or through the useClient hook
Definite reasons I can see the logs:
• Images being requested in their original quality and not optimised
• On the 22nd of Jan you also downloaded a lot (if not all) images from Sanity in their original quality and size thats basically the most effective culprit…
You can have a look yourself. All request urls with sanity tags at the end do not count against your BW, So filter them out.
One day I added in particular is Jan 22 just to let you see how those things look in detail.

In general your ways forward:
Query optimisation , optimising Images (use the image-url package and use the amazing image pipeline we offer) and I would also implement some static sites and using the API CDN if you have a lot of traffic 🙂We have some
amazing guides and docs on our site and you can check your front-end frameworks docs for more as well … Hope that helps!
Hi User,
Thank you for your help, this is all really useful. Just to confirm the reason for the high number of requests (aside from the image requests) is that the in-studio requests were being counted? Even though they’re showing in the manage project area? Could you point me in the direction of how I could configure it to use the front-end client passed down?

I will work through the other things you mentioned as well - once again thank you for your help!

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.

Get started for freeExplore the demo

Was this answer helpful?