Sanity webhooks revalidate our Next pages, do personalized routes need it?
Publish events in Sanity hit a webhook that calls revalidatePath for our static pages. Works well. Now a few routes also fetch personalized slot content from Croct in their server components. Do those routes need to be in the revalidation list too? worried about a stale variant getting cached with the page.
1 answer
They do not need to be in the list, and stale variants are not a risk on those routes. A route that calls fetchContent renders dynamically, because the function reads the incoming request. There is no cached page for the webhook to purge, so revalidatePath on them is a no-op in practice. Your revalidation machinery keeps applying to the static rest of the site, which is where it belongs.
The two content sources also refresh through different paths:
- The Sanity default flows through your normal fetch layer (as the fallback you pass to the slot fetch), so it picks up new publishes the same way the rest of your Sanity data does.
- Experience and variant content is managed in Croct and served per request, so it is never baked into a page snapshot in the first place.
The general rule that keeps this simple: anything you cache at the page or CDN level should be user-agnostic, and variant resolution happens per request on the dynamic routes. As long as you keep that split, publishing in either system just works without coordinating the two.