Sanity "Webhook" to a Vercel "Deploy URL" Trigger Not Working

You've identified exactly what's happening! This is a known timing issue when using webhooks with Sanity's CDN, and it's a common gotcha.

The Root Cause:

When you publish content in Sanity, the webhook fires almost immediately—but if your Vercel build is querying through the Sanity CDN (apicdn.sanity.io), there can be a brief window where the CDN hasn't yet updated with your latest content.

The CDN serves cached content for performance, and while Sanity does invalidate the cache when you publish edits to non-draft documents, there's still a propagation window where your build might fetch the old cached version. By the time you manually trigger a second build a few minutes later, the CDN has fully updated, which is why you see the correct content then.

Solutions:

1. Use useCdn: false for build-time queries (Quick fix)

If you're using useCdn: true in your Sanity client configuration, create a separate client specifically for build-time data fetching that queries the API directly:

const buildClient = createClient({
  projectId: 'your-project-id',
  dataset: 'production',
  apiVersion: '2024-01-01',
  useCdn: false, // Query api.sanity.io directly, bypassing CDN
})

This ensures your builds always fetch the absolute latest content directly from the API rather than through the CDN layer. The tradeoff is that you're not benefiting from CDN caching during builds, but for triggered rebuilds where you need fresh content, this is exactly what you want.

2. Use Sanity Functions instead of webhooks (Modern approach)

Rather than using webhooks to trigger Vercel deploys, consider using Sanity Functions to handle content change events. Functions run on Sanity's infrastructure and can trigger your Vercel deploy hooks, giving you more control over timing and retry logic. They're the modern, recommended approach for automation and don't require external hosting. You can add a small delay in the function before triggering the deploy to ensure CDN propagation has completed.

3. Use time-based revalidation instead (ISR approach)

If you're using Next.js with Incremental Static Regeneration, you can set a revalidate value so pages refresh periodically without needing full rebuilds:

const posts = await sanityFetch({
  query: POSTS_QUERY, 
  revalidate: 60, // Revalidate every 60 seconds
})

This eliminates the webhook timing issue entirely, though updates won't be instant—they'll appear within your revalidation window.

4. Use on-demand revalidation with direct API queries

If you prefer keeping webhooks, you can implement on-demand ISR where your webhook triggers specific path revalidation rather than full rebuilds. Combined with useCdn: false for those revalidation fetches, this gives you instant updates without the CDN timing issue. Your webhook endpoint would call Next.js's revalidatePath() or revalidateTag() functions.

5. Consider the Live Content API

Sanity's Live Content API is now generally available and provides real-time content delivery without the CDN caching delays. This works with Next.js, Nuxt, SvelteKit, and Astro via framework loaders, eliminating the need for webhooks and rebuilds altogether for many use cases. The Live Content API handles all aspects of fetching, rendering, caching, and invalidating queries automatically.

Why the second build works:

By the time you manually trigger a rebuild minutes later, the CDN's cache has definitely updated with the new content. This confirms the timing gap between webhook firing and CDN propagation.

The useCdn: false approach (solution #1) is probably your quickest fix for the current webhook + Vercel deploy setup. For a more modern approach, Sanity Functions (solution #2) give you better control over the automation flow, and the Live Content API (solution #5) would eliminate rebuilds entirely for truly instant content updates.