Sanity API CDN staleness vs live queries for a low-traffic site

Short answer

For a marketing site that only serves a few thousand page‑views a month, routing all public requests through apicdn.sanity.io is usually sufficient to stay comfortably within the free‑plan API limits. The CDN is billed as a separate, lower‑cost tier and is designed to cache published content aggressively. However, if you need absolute freshness—e.g. a live “latest news” block that must reflect every publish within seconds—then a build‑time fetch plus webhook rebuild is the safer option, because it removes runtime CDN queries entirely.

Typical CDN staleness

After a document is published, Sanity invalidates the relevant cache entries. In practice the first request after a publish usually receives fresh data within a few seconds. The CDN, however, is documented as eventually consistent, so a very small window (often <10 s) can still return the old version. You can observe this by:

1. Running curl -i https://apicdn.sanity.io/v2023-12-01/data/query/production?query=*&token=… before and after a publish.
2. Checking the Age header and the Sanity client flag cdn in the response body.

There is no hard‑coded TTL in the public docs; the Age header is the only reliable indicator of how long a response has been cached.

Preview traffic and quota

Preview/draft mode forces useCdn: false and requires a viewer token, so those requests hit api.sanity.io directly. They count against the same API quota as any other origin request. In practice preview traffic is usually negligible because only editors trigger it, but you should still monitor the API usage dashboard for your project to confirm.

When to choose each strategy

• CDN read‑through – Default for public pages. Keeps runtime origin hits to a minimum and leverages Sanity’s built‑in cache. Accept a <10 s staleness window and add a small “last updated” timestamp if you need to surface freshness to users.
• Build‑time fetch + webhook rebuild – Use when you need guaranteed freshness. Your hosting platform must support instant rebuilds (e.g. Vercel, Netlify). Be aware of the operational overhead: a failed deploy leaves stale content until the next successful build.
• Hybrid – Common pattern. Build‑time fetch for static pages, CDN for dynamic elements like search or counters. Keeps origin traffic near zero while still allowing near‑real‑time updates for the few dynamic parts.

Next steps for your project

1. Check the current free‑plan limits on Sanity’s pricing page – the numbers change from time to time.
2. Enable useCdn: true in your client for all public reads.
3. Add a lightweight “last updated” field to critical pages and display the timestamp to users.
4. If you decide on webhook rebuilds, set up a simple GET /_build endpoint on your host and point the Sanity webhook to it.
5. Use the Sanity usage dashboard to compare actual request counts against the free‑plan allowance after a week of traffic.

Diagnostic detail needed for a tighter recommendation

Could you share the approximate number of page‑views per month you expect? That would help determine whether the CDN alone is statistically safe for your quota.