Using Strapi Webhooks with Next.js Revalidation

In a Next.js App Router project, a Strapi publish can refresh affected pages through a webhook and Route Handler. The handler validates the request, maps the event to routes or cache tags, and returns a result Strapi can record. It never trusts a path supplied by the sender.

The Next.js revalidatePath documentation explains that a Route Handler marks a path for revalidation and the next visit refreshes it. I verify the public page after the call instead of treating the function return as fresh content.

Define the events that matter

I subscribe to publish, update, unpublish, and delete events that affect public content. Draft saves do not need public revalidation. The payload includes the content type, document identifier, locale, and current slug where available.

I keep the payload small and avoid sending the full private record. The Next.js handler can fetch approved fields from Strapi when it needs more context.

Authenticate the webhook

The endpoint accepts POST and validates a secret or signature stored in server configuration. I use constant-time comparison where the signing method calls for it, apply a body-size limit, and reject missing or malformed events before any invalidation.

The secret never appears in the URL, client bundle, or response. I rotate it like another service credential and test old-secret rejection.

Map events to known routes

A blog post can affect its article URL, the blog index, category page, tags, sitemap, and RSS feed. A service record can affect the service page and directory. I keep that mapping in code and normalize slugs before constructing paths.

I do not pass an arbitrary payload path into revalidatePath. An allowlisted mapper prevents an event from invalidating unrelated routes.

Choose paths or tags

Path revalidation is clear when one record maps to a few routes. Tags work when the same data appears across many pages. I name tags by content domain and record, then invalidate both the record tag and collection tag where appropriate.

I check the current Next.js API because cache behavior has changed across releases. The article records the version used by the application.

Handle retries without hiding stale pages

The handler returns a non-success status when validation or invalidation fails. Strapi or an external queue can retry with a cap. I attach an event ID so duplicate deliveries remain safe.

A failed event enters a visible queue or alert. Dropping it after logging leaves the editor with published CMS content and a stale public page.

Test publication through the browser

I publish a neutral test record, capture the webhook result, and request every affected public page. I repeat the test for slug changes, unpublishing, and an invalid signature.

• Only public-state events invalidate.
• Requests require a server secret.
• Routes come from an allowlist.
• Duplicate events are safe.
• Monitoring catches stale content.

Need help with Strapi?

Terry Hunt Dev builds Strapi and Next.js publishing integrations through Strapi development. Request a cache and webhook review through the contact page.