How Syncing Works: Webhooks, Polling, and Sync SLAs

Syncing between your PMS and Haven is event-driven, not schedule-driven. When something changes in your PMS — a new reservation, a price update, an edited listing — your PMS sends Haven a webhook: a signed, real-time notification delivered the moment the change happens. Webhooks are the primary sync path, and sending them promptly is the PMS's responsibility. Haven also runs scheduled safety polls, but those exist to catch anything a webhook missed. The poll intervals are a worst-case backstop, not how often your data syncs.

So the short answer to "how often does Haven sync?" is: continuously. Most changes arrive within seconds to a few minutes of you making them, because the PMS pushes them to Haven as they happen.

What happens when a webhook arrives

Every connected PMS is subscribed to send Haven webhooks for the events it supports (new and updated reservations, cancellations, listing changes, reviews, and so on). When one lands:

Verification — Haven checks the webhook's cryptographic signature to confirm it genuinely came from your PMS. Unsigned or invalid deliveries are rejected.
Acknowledgment — Haven accepts the delivery in under 5 seconds, so the PMS never has to retry a slow endpoint.
Deduplication — the raw payload is stored and duplicate deliveries of the same event are recognized and skipped.
Processing — the event is routed to the right handler (reservation, property, review, connection), which updates your Haven data in the background.

From delivery to your Haven calendar or listing reflecting the change is typically under a minute.

Sync SLAs

These are the operational targets Haven runs to once a webhook reaches us:

Stage	Target
Webhook acknowledgment	Under 5 seconds
Change materialized in Haven after delivery	Typically under 1 minute
Calendar and reservation safety poll (fallback)	Approximately hourly
Listing content and photo safety poll (fallback)	Approximately daily
Review safety poll (fallback)	Approximately every 12 hours

The first two rows describe the webhook path — the normal experience. The poll rows are the fallback: the longest a missed change should wait before Haven's reconciliation sweeps it in.

One number Haven cannot promise is how quickly the PMS dispatches the webhook in the first place. That leg belongs to the partner, and it varies by provider.

What each PMS sends, and how fast

Provider	Webhook delivery
Lodgify	Most changes within seconds. Haven re-checks the subscription every 15 minutes and re-subscribes any webhook Lodgify has dropped.
Guesty	A few seconds to about 30 minutes, at Guesty's discretion. Sustained delivery failures can lead Guesty to disable the endpoint on its side (roughly five days of failures).
OwnerRez	Prompt under normal conditions. OwnerRez may automatically disable a subscription after sustained failures; reconnecting restores real-time delivery.
Hostfully	Webhooks for listings, calendars, reservations, reviews, and guest messages; Haven direct bookings are created in Hostfully in real time.
Hospitable	Webhooks for property, reservation, review, message, and connection changes. Hospitable sends no calendar webhook, so calendar pricing, stay rules, and availability travel on the hourly poll — the one place polling is the normal path rather than the fallback.
Airbnb (direct)	Listing, calendar, reservation, and review events by webhook, with the standard polls as the safety net.

For the full event matrix per provider, see the sync references: Hospitable, Guesty, Lodgify, OwnerRez, and direct Airbnb.

The polling safety net

Webhook delivery over the public internet is never perfect — a delivery can be delayed, dropped, or a partner can silently disable a subscription. Haven's scheduled polls exist so a missed webhook costs you a bounded wait instead of stale data:

Calendars and reservations — approximately hourly, with about a 50-minute per-connection cooldown. Lodgify polls every few minutes.
Listing content and photos — approximately daily (about a 23-hour cooldown). Lodgify's property poll is approximately hourly.
Reviews — approximately every 12 hours.

Because these are reconciliation sweeps, the poll interval is the maximum staleness after a lost webhook — not the cadence your data normally moves at.

If changes seem slow to arrive

A change that reliably takes close to a full poll interval to show up is a sign the webhook leg is not doing its job — the poll is catching what the PMS should have pushed. In that situation:

Check the connection's status on Host Dashboard → Integrations. A card that needs reconnecting cannot receive some updates, and reconnecting also restores webhook subscriptions a partner has disabled.
Click Sync now on the connection's card to pull listings, photos, calendars, and reservations immediately rather than waiting for the next poll.
If delivery stays slow after a reconnect, the delay is happening inside the PMS before the webhook is sent — their support can confirm webhook health on their side.

Remember the Hospitable exception: calendar data there is poll-driven by design, so an hour-scale wait for a Hospitable price or availability change (without clicking Sync now) is expected behavior, not a fault.