# Sanity webhooks revalidate our Next pages, do personalized routes need it?

Asked by Adeola Ogun on 2026-01-28. Tags: sanity, webhooks, caching, nextjs.

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

### Answer from Sofia Marinho (2026-01-29)

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.