Connect Booking engine to SiteOps

A hotel, a clinic and a restaurant all sell the same thing: a slot on a calendar. The moment that matters is a confirmed reservation — and until SiteOps can read it, the Bookings KPI is resting on a proxy: a button click, a page view, an intent that may never have become a booking. That's the wall Azure Bay, BrightSmile and Wandergram all hit.

Connecting your booking engine or PMS puts the real number in place. Cloudbeds, Mews or SiteMinder for a hotel; NexHealth or Calendly for a clinic; OpenTable, Resy or Toast for a restaurant — whichever holds your reservations, SiteOps reads confirmed bookings and stands them next to your marketing, read-only. When the goal type is Bookings, the hero KPI stops being a hopeful proxy and becomes what actually happened.

It reads, and only reads. SiteOps never takes, moves or cancels a reservation, and never touches a guest's details beyond the totals it needs to count. Disconnect and the reads stop the same minute.

Reservations flow in, read-only — SiteOps never takes a booking

Set it up, step by step

0 of 4 done

1. Settings
2. Connections
3. Booking engine

If something does not work

My engine isn't in the list: The booking connector is written to the common shape most schedulers and PMSs share — a read-only key or an authorize screen. If yours offers either and isn't recognized, connect it as a generic booking source and pick its property; if it offers neither, it can't be read yet, and the Bookings KPI stays honestly on its proxy with the warning showing.
Bookings show but the value is missing: Not every engine reports a per-booking value over its API — some only expose the count. SiteOps shows what it's given: the booking count always, the value only when your engine sends it. A count with no value still lights the KPI honestly.
Can SiteOps take or cancel a booking?: No — by construction. The connection is read-only; there is no code path that creates, edits or cancels a reservation. Your calendar is safe from us.
The count differs from my engine's own dashboard: SiteOps reads on a short delay and counts confirmed bookings for the period shown — a reservation made minutes ago, or a cancellation, may not have synced yet. A small, settling gap is normal; a large persistent one usually means a different property or date range.

What it unlocks

The Bookings KPI on real reservations instead of a click proxy — the honest conversion for a hotel, clinic or restaurant.
Booking value carried through where your engine reports it, so a night's stay and a lunch table aren't counted the same.
An honesty warning lifts: with a real source connected, the hero KPI stops flagging that bookings are unmeasured.
Reservations sit next to traffic and ad spend, so a campaign's real cost-per-booking becomes something you can read.

Before you start

A booking engine, scheduler or PMS that holds this business's reservations and offers an API or an integration you can authorize.
Admin access to that system — the key or OAuth screen usually sits under its settings, integrations or developer area.
If the account manages several properties or calendars, know which one this project is. You pick it during connect.

Quick links

What SiteOps reads

Bookings — confirmed reservations, with their booking value and dates where your engine reports them.
Enough to compute a real cost-per-booking against your connected ad and marketing spend.
SiteOps writes nothing back: it never creates, moves or cancels a reservation, and touches no guest detail beyond the totals.
Disconnecting in SiteOps, or revoking access in your engine, cuts the reads instantly.

Connect Booking engine to SiteOps

Set it up, step by step

If something does not work

Set up once, see everything every morning