--- type: Leaf title: What Stays Yours When You Integrate Newbook, SiteMinder, RMS or a Cruise Reservation System description: How Newbook, SiteMinder, RMS Cloud and cruise reservation APIs get scoped for booking flows, and what your subscription keeps. Get in touch. resource: https://nationaldigital.com.au/digital-product-development/booking-and-scheduling-systems/booking-platform-integrations/ tags: - digital-product-development - Booking and scheduling systems - Reservation platform integration - Travel and accommodation technology - newbook api - newbook integration - siteminder integration - rms cloud api - cruisepal integration - booking engine integration - channel manager integration - custom booking flow reservation system - cruise reservation system integration timestamp: "2026-11-02T06:47:19.817Z" language: en-AU publisher: National Digital author: Cameron Young authorRole: CEO reviewedBy: Tara Buckley reviewedOn: "2026-11-02" readingTimeMinutes: 8 wordCount: 1574 datePublished: "2026-11-02" dateModified: "2026-11-02" pillar: digital_product_development canonical: https://nationaldigital.com.au/digital-product-development/booking-and-scheduling-systems/booking-platform-integrations/ sourceCount: 1 --- *8 min read · Updated 2 November 2026* # What Stays Yours When You Integrate Newbook, SiteMinder, RMS or a Cruise Reservation System An integration built against Newbook's, SiteMinder's or RMS Cloud's own API leaves the reservation platform, its subscription and its support arrangement exactly where they are. **Quick answer:** Newbook, SiteMinder, RMS Cloud and cruise systems like cruisePAL each expose different APIs; integrations build on top of them without replacing the subscription or support. Booking and scheduling systems · Reservation platform integration · Travel and accommodation technology *Quick answer* ## How do you build a custom booking flow on the Newbook API, SiteMinder or RMS Cloud without losing the reservation system? *High confidence · Verified 1 Nov 2026* Integrate against the platform's existing API for availability, rates and bookings, so the operator's subscription and support stay in place. **Additional Context:** Cruise reservation systems such as cruisePAL work the same way: the integration is scoped directly against the vendor's API. ### Sources - [Characteristics of Australian Business, 2021-22](https://www.abs.gov.au/statistics/industry/technology-and-innovation/characteristics-australian-business/2021-22) — 59% of Australian businesses reported using cloud technology in 2021-22. *Platform by platform* ## How Newbook, SiteMinder and RMS Cloud expose their APIs 59% ([Australian Bureau of Statistics, 2023](https://www.abs.gov.au/statistics/industry/technology-and-innovation/characteristics-australian-business/2021-22)) of Australian businesses now run some form of cloud technology, and that shift explains why Newbook, SiteMinder and RMS Cloud are all delivered as API-first SaaS products operators log into from a browser. Each exposes that API differently, and the shape of the API sets the real scope of any custom build. Newbook publishes a REST API covering availability, tariffs, guest profiles and bookings, so most custom work here is a booking widget, guest portal or loyalty integration sitting on top of an existing Newbook account. SiteMinder works differently: it's a channel manager first, and its API mostly pushes rate and inventory data out to OTAs. An integration usually means pulling that distribution data into internal reporting, or connecting an extra channel SiteMinder doesn't support natively. RMS Cloud's API exposes PMS, trust accounting and guest data, and the common build there is a CRM sync, a marketing feed, or a booking engine that calls RMS for live rates and writes the reservation back once a guest confirms. None of these projects replace the platform underneath; the API is the seam a custom front end, portal or report sits on. Keeping bookings consistent across that seam usually comes down to [availability locking](/digital-product-development/booking-and-scheduling-systems/real-time-availability/) at the moment a guest commits to a date, so the custom flow never shows a room, site or cabin the core system has already sold. ### Cruise reservation systems run on an older integration pattern cruisePAL and similar cruise reservation platforms from vendors such as Rescompany Systems (Resco) sit further back from the web than a property management system typically does. Many expose SOAP or flat-file interfaces built for travel agent terminals and back-office reconciliation. A guest-facing voyage search and cabin selection flow has to be built as a translation layer: it reads cabin categories, deck plans and departure schedules from the reservation system's native format, and writes the booking back through the same interface once it's confirmed. National Digital integrated an Australian expedition cruise operator's booking site with cruisePAL, the central reservation system from Rescompany Systems (Resco) ([service](/digital-product-development/booking-and-scheduling-systems/)) A multi-leg voyage deposit rarely settles in a single card charge, and that needs its own [PCI DSS tokenisation](/digital-product-development/booking-and-scheduling-systems/payment-integration/) layer to handle deposits, balances and refunds correctly. *Common failure mode* ## Why some booking integrations blow their scope ### Problem Many booking integration briefs start by describing a brand-new engine, before anyone checks what Newbook, SiteMinder or RMS Cloud already owns: the live inventory, rates and guest record. The new build then either duplicates that data or ends up fighting the platform for control of it. **Common Pain Points:** - **Duplicate availability** The custom site and the reservation platform disagree about what's free, usually discovered when a guest double-books. - **Undocumented rate limits** The vendor's API throttles or locks the account mid-build because nobody checked the limits before designing around them. - **Fields the platform doesn't expose** Loyalty tiers, package inclusions or cabin metadata the brief assumes exist, but the vendor's API doesn't return. **Business Impact:** - **Time Wasted:** Rework when two systems end up holding different availability for the same room, site or cabin - **Cost Implication:** Development effort spent reconciling two copies of the same booking data instead of building the guest-facing experience - **Opportunity Cost:** Staff keep manually checking both systems before confirming a booking, instead of trusting either one ### Solution Scope the integration against the platform's existing API from the outset, so the custom layer reads and writes through the vendor's own data model and never keeps a second copy of availability and rates. **Our Approach:** 1. **Map the API's real boundary** *(Before design starts)*: Document which endpoints the vendor actually supports, their rate limits and the fields their data model doesn't expose, before any screen is designed. 2. **Design around the gaps** *(During scoping)*: Decide, for each missing field or workflow, whether it's held in the custom layer, requested from the vendor, or left out of the build entirely. 3. **Build the translation and locking layer** *(During build)*: Implement the booking flow against the vendor's sandbox, with availability locking and webhook handling tested against real vendor outages and retries. 4. **Cut over against production data** *(Before go-live)*: Switch the custom flow to the live API once sandbox behaviour and production behaviour have been checked side by side. **Expected Outcome:** A booking flow that matches what the reservation platform itself shows, with no second source of truth to keep in sync. *Key Takeaways* ## What to settle before scoping a booking integration - **SiteMinder, Newbook and RMS Cloud expose different kinds of API, and that shape sets what's buildable.** *Critical* — SiteMinder's API mostly feeds OTAs rate and inventory data, while Newbook and RMS Cloud expose guest, tariff and booking data a custom flow can call directly. - **Cruise reservation systems like cruisePAL often use older SOAP or flat-file interfaces.** *Important* — A guest-facing voyage booking flow has to translate between that older format and a modern web experience, both reading and writing bookings back through the same interface. - **The vendor subscription, support contract and back-office workflow stay in place.** *Critical* — Because the integration reads and writes through the existing API, staff keep using the reservation platform they already know for everything except the new booking flow. - **Undocumented edge cases cause more delay than the booking call itself.** *Important* — Concurrent amendments, sandbox-versus-production mismatches and webhook retries during vendor outages are the failure states that extend a project's first estimate. Scoping a Newbook, SiteMinder, RMS Cloud or cruise reservation integration starts with the vendor's API limits, not the screen designs. Done that way, the operator keeps its platform, its support and its back-office process, and only the layer guests touch changes. *Scoping the build* ## What actually gets scoped, and what the operator keeps A scoped integration starts from the API documentation each vendor publishes. The first working session usually maps three things: which endpoints return live availability and rate data, what the authentication and rate-limiting rules allow before they throttle or lock the account, and which fields the vendor's data model doesn't expose at all (loyalty tier, package inclusions and deck-plan metadata are common gaps). That mapping sets the real boundary of the build, well before the first design mock-up gets drawn. Everything downstream, the guest-facing booking flow, the staff dashboard, the [timezone-aware reporting](/digital-product-development/booking-and-scheduling-systems/reporting-analytics/) finance actually trusts, gets built against that boundary. What stays the same is the part operators worry most about losing. The Newbook, SiteMinder or RMS Cloud subscription continues, support tickets for platform-level issues still go to the vendor, and existing staff training and back-office process carry over because the core system hasn't moved. The layer guests and finance actually touch is what changes. The [cruise booking website](/case-studies/coral-expeditions/) rebuild is a useful comparison from a different distribution problem: the booking experience was redesigned end to end around a typed API layer, while the underlying reservation data model stayed exactly where it was. ### Where teams underestimate the work The part that catches teams out is rarely the happy-path booking call. It's the edge cases the vendor's API documents but nobody reads closely until testing starts: what happens when two staff members amend the same booking in the vendor's back office while a guest is mid-checkout on the custom site, how cancellation windows and refund rules differ between the API's sandbox and production environments, and how webhook retries behave during a vendor outage. A scoping document that lists only the screens to be built, and skips these failure states, is a common reason an integration project runs past its first estimate. ## Scope your booking integration against the platform you already run Tell us which reservation system you're on, Newbook, SiteMinder, RMS Cloud or a cruise platform, and we'll map what the API supports before any build starts. - [Talk to National Digital](https://calendly.com/cameron-at-national-digital/discovery) - [Explore booking and scheduling systems](/digital-product-development/booking-and-scheduling-systems/) or · [1300 800 855](tel:+611300800855) ## Questions about integrating these reservation platforms ### Can I build a custom website on top of Newbook without replacing the property management system? Yes. Newbook's REST API returns availability, tariffs and booking data, so a custom site or guest portal can call it directly for live information and write bookings back, while Newbook itself keeps running the property's day-to-day operations. ### Is SiteMinder's API suitable for a custom guest-facing booking flow? Not usually on its own. SiteMinder's API is built to distribute rates and inventory to OTAs through the channel manager. Most integrations pull that distribution data into internal reporting, or connect an extra channel it doesn't support natively. Taking bookings directly from guests isn't the API's typical job. ### What's different about integrating RMS Cloud compared with Newbook? The API shapes are similar in intent, covering PMS, trust accounting and guest data, but the field names, authentication model and rate limits differ. A build tested against one vendor's sandbox still needs its own mapping and testing pass against the other's. ### How does integrating a cruise reservation system like cruisePAL differ from a hotel or holiday park booking integration? Cruise reservation systems often expose older SOAP or flat-file interfaces built for travel agent terminals. The integration needs a translation layer that reads voyage, cabin and deck-plan data in the vendor's native format and writes confirmed bookings back the same way. ## References - Australian Bureau of Statistics. (2023). *Characteristics of Australian business, 2021-22 financial year*. Written by [Cameron Young](/about/cameron-young/), CEO Reviewed by [Tara Buckley](/about/tara-buckley/), COO, on 2 November 2026 ## Related reading - [Real-time availability in booking systems](/digital-product-development/booking-and-scheduling-systems/real-time-availability/) - [Payment integration for Australian booking systems](/digital-product-development/booking-and-scheduling-systems/payment-integration/) - [Reporting analytics for Australian booking data](/digital-product-development/booking-and-scheduling-systems/reporting-analytics/) ## Related **Parent:** - [Custom booking and scheduling systems in Australia](/okf/digital-product-development/booking-and-scheduling-systems.md) # Citations 1. [Characteristics of Australian business, 2021-22 financial year](https://www.abs.gov.au/statistics/industry/technology-and-innovation/characteristics-australian-business/2021-22)