From Payload CMS to a Live Booking Page in Under a Minute: How Moven's Content Pipeline Works

One of the things I got wrong in an early version of Moven was how content updates worked. An operator would change their villa description or upload new photos, and the live website would reflect that change... sometime in the next hour, once we manually triggered a rebuild. That's not a content pipeline — it's a queue with a human bottleneck. Here's what we built instead.

The Problem: Decoupled CMS and Decoupled Website

Moven uses Payload CMS as its content management system and Next.js as the frontend. These are separate systems talking to each other via API. When an operator saves a change in Payload CMS, nothing automatically happens on the Next.js frontend — the cached static pages are stale until something tells Next.js to regenerate them.

In the early version, that something was a manual script. That meant an operator changing their amenity list at 9 AM would see the live page reflect the change whenever a developer next ran the script. Sometimes that was 20 minutes. Sometimes it was 4 hours. That's not acceptable for a platform that wants to be reliable.

Webhooks: The Trigger

The solution was webhooks — automatic HTTP notifications that Payload CMS sends whenever content changes. Every time an operator saves a villa page, a blog post, or an update to their property details, Payload fires a POST request to a webhook endpoint on our Next.js application.

That webhook endpoint receives the notification, identifies which pages have been affected by the change, and calls Next.js's on-demand ISR revalidation API. This marks the relevant cached pages as stale and triggers background regeneration. The entire process — from save in CMS to queued regeneration — takes under 1 second.

ISR On-Demand Revalidation

Next.js 13+ supports on-demand ISR revalidation via a special API route. When you call it with a path, Next.js invalidates the cache for that path and regenerates it in the background. The current cached version serves normally until regeneration is complete — there's no downtime, no blank page, no error state.

For Moven, we trigger revalidation on: the specific property page that was updated, the property listing page for the operator's site, the sitemap (so updated content gets discovered by Google faster), and any pages that aggregate data from the updated record.

What This Means for Content Editors

The end result for an operator is: they save a change in the CMS, they wait 30–60 seconds, they refresh the live page, and they see their change. No developer intervention required. No waiting for a rebuild. No confusion about why the live site looks different from the CMS.

This matters because the people managing villa content are operators and their staff, not developers. They shouldn't need to understand deployment pipelines or send a Slack message to update a photo. The feedback loop between 'I changed something' and 'I can see the change' needs to be short enough that they can do it themselves.

Payload CMS: Why It Works for This Use Case

We chose Payload CMS over Contentful, Sanity, or Strapi for a few specific reasons. First, it's TypeScript-native, which means our schema definitions are the same language as the rest of the codebase — no impedance mismatch between the CMS's concept of a villa and the frontend's. Second, it supports complex relational data: a villa has many rooms, each room has many images and amenities, each villa belongs to a tenant with its own theme.

Third — and this was practically important — Payload's webhook system is configurable per-collection. We can set different revalidation rules for villa updates, tenant changes, and blog posts without writing custom middleware.

The Broader Principle

The content pipeline is a microcosm of a broader principle that shaped Moven's architecture: operators are the users, not the developers. Every technical decision should be evaluated partly by asking: does this make life easier or harder for a non-technical operator who needs to update their property page at 10 PM before a guest checks in tomorrow morning?

The answer to that question has guided us toward shorter feedback loops, simpler interfaces, and less reliance on developer intervention for routine operations. The webhook + ISR pipeline is one concrete implementation of that philosophy.