Understanding the impact of using Sanity's `imageUrlBuilder` on API quotas and bandwidth.

10 replies
Last updated: Jul 6, 2022
Quick question: does Sanity's
imageUrlBuilder
count towards the API quotas?
AI Update

Good news—imageUrlBuilder itself doesn't count towards any API quotas. It's purely a JavaScript utility that constructs URL strings for you. No API calls happen when you're building those URLs.

However, when browsers actually fetch and display the images using those URLs, that's when you're using resources—specifically bandwidth. The images are served through Sanity's Asset CDN at cdn.sanity.io, which is a separate system from the API CDN (Live CDN) that serves content queries.

What counts toward quotas

When images are requested:

  • Bandwidth: The actual size of the image file counts toward your bandwidth quota
  • Asset storage: The stored assets count toward your asset storage quota

Importantly, images served through the Asset CDN do NOT count as API CDN requests. These are different systems—the Asset CDN handles media delivery, while the API CDN handles content query responses.

Caching benefits

The Asset CDN is built on Google's global CDN infrastructure and caches assets indefinitely once processed. This means:

  • The first visitor triggers bandwidth usage when the image is fetched and cached
  • Subsequent visitors get the cached version without additional bandwidth impact
  • The content-addressable URLs (with SHA-1 hashes) ensure aggressive caching works reliably

Plan quotas

Looking at Sanity's pricing, the bandwidth limits are:

  • Free plan: Includes a baseline amount of bandwidth
  • Growth plan: More bandwidth included, with the Increased Quota add-on ($299/month) bumping it to 500GB

If you're serving lots of images, the main thing to watch is your bandwidth usage, not API request counts.

We're iterating over some arrays at the moment, and if so, has the potential to fry our quotas pretty quickly given our estimated traffic.
.
as far as i understand, the
imageUrlBuilder
is just a utility that makes URL strings for you. it doesn't make API calls during that process. But then when you fetch the image, that counts towards your API usage.
Got it - and am I safe to assume the images would then apply to the bandwidth cap versus the API CDN cap? Or would it be both?
good question. i don't know actually. maybe someone else knows 🙂
I also don't know for sure but from experience and reading the logs and comparing them with my server logs, I believe that the API CDN cap is for the requests themselves -- the textual returned data, part of which is to identify and return the information about the images.
The bandwidth seems to be a mixture of both -- all the data passing through, in terms of what the queries burp out, and almost certainly any image transformations. I don't believe the actual egress of file data is "cached" in any way in that regard, because, well, being held in memory doesn't make it any less made of bytes and that's what has to get pushed to the end user.

So as you can clearly see.....I
also don't know but used more words to say it 😛
user E
you'd be using both an API request and bandwidth when displaying an image, I believe: 1 call to get the asset and bandwidth in the amount of whatever size that asset you're serving is.
Thanks for the insight
user M
! On that note, I'm wondering if there's a more efficient way to do what we're doing. Ex: we have a landing/gallery page that lists out many cards (with thumbnail images) that link to the respective detail pages. A single query grabs the refs to all the images, but we're looping over that dataset in a Vue template and calling the URL builder for each image, which could potentially lead to dozens of API calls on that page alone.
Is there a better way to handle that?
Good question! You can expand the asset ref in your original query to get the image url, then add whatever params you need using string concatenation on your frontend. That means getting all of those urls is a single call, not 1 call x however many images you're building a url for. The downside is that you're not getting the benefits that the builder affords you (I.e. respecting crop & hotspot automatically).
If you want to continue using the builder, though, you can mitigate the impact of these calls by using the CDN (which affords you about 5x the number of calls).
Awesome, will have a deeper look.

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?