Global Booking Systems
Profiles of the third-party accommodation booking engines a property may hand off to — their booking domains (whitelist targets) and how each one handles custom data, client-ID, conversion echo, GA4 and GTM across the off-site handoff.
Use it as a fast way to find the data gap: when a property hands a booking off to a third-party vendor, this shows what happens to your tracking data — which vendors have a working solution (open / patched) and which don’t (closed) — and links straight through to each vendor’s own documentation and API.
Last researched June 2026 · verify vendor docs before quoting in a client-facing report — help-centre URLs move.
The Data Bridge
For each engine we answer six questions — what survives the off-site handoff, and what can be recovered:
How to read each engine
Type the booking URL a site hands off to (or the company) — click a result to jump to its profile.
No booking domain or company matches that search.
35 of 35 booking domains across 25 engines
The home-turf cluster — dominant across AU motels, holiday parks, caravan parks, B&Bs and boutique properties.
SiteMinder — The Booking Button#
SiteConnect / pmsXchange Reservations Push delivers each booking to the PMS in real time — but it is PMS-direction sync, not keyed to a website visitor ID.
Guest completes on thebookingbutton.com. Without correct cross-domain tracking, conversions land as referral/direct and paid spend mis-attributes.
Full partner-gated suite — SiteConnect, Channels Plus, pmsXchange and SMX (reservations push). Publishes an llms.txt and an MCP path for Channels Plus.
Little Hotelier#
Shares SiteMinder’s SiteConnect reservation-sync backend; not visitor-ID keyed.
Same cross-domain handoff — many operators never configure it, so attribution is usually broken from day one.
No separate developer API of its own — rides SiteMinder’s SMX backend (and SMX cannot even pull ARI from Little Hotelier).
NewBook#
Developer API and reservation webhooks let a dev pull booking data, but there is no native website-visitor-ID echo.
BE on a NewBook domain needs cross-domain config; multi-product carts (sites/cabins/powered) complicate ecommerce mapping.
Strong REST API (v1 and v2); HTTP Basic auth + region/api_key; includes a push-notification endpoint. Keys issued by NewBook Support.
RMS Cloud#
BE path carries the property’s RMS Client ID + Agent ID (property identity, not a marketing ID). REST API exposes reservations; no native visitor-ID echo.
The Cross-Domain Tracking URL field must be set or sessions split. Running GA4-in-RMS and GA4-inside-GTM together double-counts events.
REST API (Swagger) + Channel API (SOAP/OTA). ~AUD $550 developer kit, API-token auth, sandbox available.
Preno#
No documented visitor-ID-keyed return.
Confirmation is a hash fragment (#confirmation), not a path — GTM triggers must read the hash, a classic mis-config that silently drops conversions.
Many pre-built integrations (SiteMinder, STAAH, Xero, RoomPriceGenie) but no public developer API portal found — likely partner-only or none.
Bookeasy#
Strong audit hookDestination model — bookings flow through a VIC/marketplace and commission reconciliation is internal; no operator-facing visitor-ID webhook documented.
The cleanest “your conversions are invisible to you” case — in the destination model the operator often owns neither the checkout domain nor the analytics.
External Developer Guide — a gadget/embed-based booking API built for the destination model.
Netbookings#
Not documented as visitor-ID-keyed.
Multi-channel surfaces (web, Facebook app, mobile) fragment the journey; cross-domain still required on the web flow.
No public developer/API docs surfaced; native GA/GTM/Pixel exist but no documented data API.
HiRUM / HiSITE#
Open API on request (PMS/CRS integration); not a visitor-ID echo. Expect migration toward Guesty’s booking-engine tooling.
Thin public tracking docs + cross-domain handoff = attribution usually unconfigured; the ownership transition adds version uncertainty.
HiSITE “open API on request”; now a Guesty company, so expect migration to Guesty’s documented APIs.
Seekom (iBex)#
API available; not visitor-ID keyed.
Cross-domain config required; the non-iframe embed helps but does not remove it.
RESTful iBex API, OAuth2, full booking flow. (One aggregator wrongly says “no API” — the dev docs exist.)
ResBook → CobberRes#
Visitor-ID return undocumented. Legacy ResBook offered Google Analytics; confirm current CobberRes docs.
Mid-rebrand — verify before quoting specifics.
Rebranded into the Cobber suite; CobberX is “one simple API.” Accommodation-PMS-specific API details not fully public.
STAAH#
API + reservation delivery to the PMS; not visitor-ID keyed.
BE on staah.net / staah.com → cross-domain required.
ChannelConnect API for channel/partner connectivity; partner-gated.
Global platforms, common across AU. Boutique/independent and vacation-rental focus.
RoomRaccoon#
Strong client-side data layer pushes add_to_cart → purchase (booking ID + value + currency) on the confirmation URL — but it is client-side, not a server webhook keyed to your ID.
E-commerce tracking is a Tier-3+ paid feature; on lower tiers the data layer is unavailable. Cross-domain mandatory unless white-labelled.
Partner API via marketplace certification (~30-min call). No fully public self-serve portal; the partner program confirms it.
Sirvoy#
Reservation API/webhooks exist; not visitor-ID keyed.
Cross-domain required; GA4 event setup is manual.
Explicitly states no open API — only iCal + a “URL callback / webhook API.”
Profitroom#
API available; not visitor-ID keyed.
Cross-domain required; confirm current GA4 ecommerce event coverage in their docs.
Partner marketplace + talks about APIs, but no public developer portal/spec surfaced.
Mews#
Strong audit hookRich client-side data layer (transaction_id, value, tax, currency, items) plus a full Open API with reservation webhooks — but not keyed to a website visitor ID by default.
Documented complaint that 60%+ of online revenue mis-attributes to “Direct”. Mews disclaims support for complex setups and flags ~33% ad-blocker loss.
Fully open — three documented APIs (Connector, Channel Manager, Booking Engine) + OpenAPI/Swagger + webhooks + llms.txt. Token-pair auth; certification to go live.
Guestline#
API / integration layer; not visitor-ID keyed.
Cross-domain required; less granular public tracking documentation than Mews / Cloudbeds.
Developer portal for Rezlynx PMS APIs + Guestpay docs; on-boarding / credentials process.
eviivo#
Booking API exists (real-time availability/rates/reservations) — a dev could reconstruct, but no native visitor-ID echo.
Widget-embed vs hosted-page behaviour differs; iframe widgets are a known GA blind spot.
Multiple open APIs — Distribution, Booking, Invoicing, Guest Check-In, Accounting ERP + webhooks; API key issued on request.
Lodgify#
API + Zapier/Pipedream booking triggers can push a conversion event to GA4 — a workable automation path, but bolted-on and not natively keyed to the website visitor ID.
Inquiry-style conversions often need a thank-you-page event; if the property maps its own domain, whether cross-domain applies depends on setup.
Public REST API (key from Settings → Public API), webhooks, status page. Available on higher tiers.
Smoobu#
API / webhooks exist; not visitor-ID keyed.
Smoobu states its support team is not trained on Google Tags — correctness sits with the operator, and the conversion-tag field is frequently left blank.
Public REST API (api-key header), reservation create/cancel, webhooks; separate partner auth.
Global platforms, common across AU. Independents, hostels, groups and enterprise CRS.
Cloudbeds#
Strong client-side data layer plus a full API + webhooks for reservations — best-in-class building blocks, but the visitor-ID stitching is still on you (the API returns bookings, not the website client ID).
Pick either GA4-direct OR GTM (not both) or you double-count; cross-domain mandatory; role permissions needed to save tags.
Full public REST API (v1.2), GraphQL, OpenAPI, webhooks, llms.txt, self-service keys + OAuth2. (Already in the stack via LMBK.)
SynXis (Sabre Hospitality)#
Native data layer + GTM container carry Enhanced-Ecommerce + conversion tokens. Client-side; enterprise CRS APIs exist but are not visitor-ID keyed by default.
Well-documented breakage where DOM-Ready triggers on gc.synxis.com intermittently fail, dropping ecommerce hits. Setup is complex and usually agency-built.
Extensive REST APIs (availability, reservations, profiles, Property Hub) on the Sabre Hospitality dev portal; partner-gated, enterprise.
WebRezPro#
Strong audit hookDoes NOT natively feed GA4 / Google Ads / Meta — agencies build custom scripts to push booking revenue. Reservations track by “market code,” not by website visitor ID.
The standout “your tracking is almost certainly broken” engine — no documented turnkey conversion integration, so the gap is effectively invisible without custom work. (v11 BE may improve — verify.)
API exists but partner-based only (AppConnect / Hapi) — no public self-serve developer portal. The weakest documented one on this list.
innQuest — roomMaster#
API exists; not visitor-ID keyed. Older lineage suggests limited native ecommerce tracking — verify current cloud version.
Treat like WebRezPro — likely a real attribution gap; confirm before quoting.
Now ships the Agora OpenAPI — open today, comprehensive docs + free sandbox. (Upgrade from the prior “undocumented” status.)
Hotelogix#
API available; not visitor-ID keyed.
Cross-domain required; verify live GA4 documentation depth.
Web API — XML POST over HTTP, HMAC-SHA1 signing, keys on request, demo endpoints.
Guesty#
Strong audit hookBooking Engine auto-sends events to GA4 (page-view, object-view, checkout, purchase) via gtag(); strong client-side events + API/webhooks, but not natively visitor-ID keyed.
Meta Pixel purchase sends reservationTotalAmount, not value — so Meta Ads Manager cannot compute ROAS out of the box (a precise, quotable defect).
Two fully documented APIs — Open API + Booking Engine API; OAuth2, OpenAPI, llms.txt, webhooks. The only engine here shipping an official MCP server.
This is internal reference material. Capabilities change as vendors ship updates and rebrand — confirm the live vendor documentation before quoting specifics in any client-facing report.
We plant Data Trees. You Harvest Insights.