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

Goal

We run a low-traffic marketing site backed by a single Sanity dataset (assume a current Sanity v3-era project and a static frontend). To stay within free-plan API allowances, we want to cut runtime API usage as much as possible without breaking the editing experience.

Constraints and uncertainty

The documented options seem to be: query the cached CDN endpoint (apicdn.sanity.io) at runtime, or fetch content at build time and rebuild via webhook on publish. Both reduce origin API load, but CDN responses are eventually consistent, and build-time snapshots go stale until the next deploy. Meanwhile, preview/draft mode must bypass the CDN and hit the live API, which we expect but have not budgeted for.

We have not yet measured our actual monthly request volume against current plan quotas, and we know pricing and limits change, so we will verify those on the official pricing page before committing.

Questions

• For a low-traffic site, is routing all public reads through apicdn.sanity.io sufficient to stay comfortably within free-tier API limits, or is build-time fetching with webhook rebuilds meaningfully safer?
• How long does CDN staleness typically last after a publish, and is there a documented way to confirm freshness from response headers?
• Does preview-mode traffic against the live API count toward the same plan quota as public API requests?