Revalidation

The app subscribes to XP repository and node events for projects containing a site configured with Next.XP. Published changes are sent to the front end selected by that site’s configuration.

The subscriber runs on the XP cluster master so a clustered installation does not send the same notification from every node. Bulk events are debounced before the front end is called.

Normal publish events invalidates the affected site. Move and rename events also retain the previous path, allowing both the old and new public routes to be invalidated.

The active XP project is sent in the Content-Studio-Project header. The front end uses it to resolve the correct locale and project mapping before invalidating paths.

The app calls the protected /api/revalidate route on the selected Next.js front end. The starter provides the canonical route handler; a custom front end must implement the same integration contract.

The handler validates the shared token and applies Next.js path revalidation to the affected routes or the entire site, depending on the presence of the path parameter. The front end remains responsible for its caching policy and for any additional tags or application-specific caches.

See Caching and revalidation for the corresponding Next.js behavior.

The destination URL and token come from the site’s selected entry in com.enonic.app.nextxp.cfg. The token must match ENONIC_API_TOKEN env var in the front-end deployment, and /api/revalidate must reject requests with an invalid token.

XP must be able to reach the configured URL from the cluster master. Use HTTPS outside a trusted local network and use a unique secret for every shared or production environment.

See App configuration for the target and secret properties.