Hotel distribution runs on data that never stops moving — availability, rates, restrictions, and reservations flowing between property systems and dozens of booking channels every minute of every day. SiteMinder sits in the middle of that flow for more than 47,000 properties worldwide, and the way third-party systems plug into that network is through one of five purpose-built APIs.

If you're building a PMS, an RMS, a booking channel, or a guest-facing application and you've landed on SiteMinder's developer portal wondering which API applies to you, this guide walks through the full picture: what each API does, how the underlying architecture works, what the certification path looks like, and what to prepare before you write your first line of integration code.

What Is the SiteMinder API?

"The SiteMinder API" isn't a single product — it's a family of five APIs, each built for a different type of integration partner. Which one you need depends entirely on what kind of system you're connecting.

Some integrations combine more than one API. An RMS, for example, typically pairs pmsXchange (to push rates and restrictions) with SMX (to pull reservation data for pricing decisions).

pmsXchange: The PMS and RMS Integration API

pmsXchange is the API that connects Property Management Systems, Revenue Management Systems, and Central Reservation Systems to the SiteMinder Platform. It's a two-way integration: PMS partners push real-time rates, availability, and restrictions to SiteMinder while pulling reservations — including modifications and cancellations — back into the property system. RMS partners use the same API to push optimized pricing without needing the reservation-retrieval components.

Key technical characteristics:

• Protocol split. Most of pmsXchange runs on SOAP 1.1 using Open Travel Alliance (OTA) 2003/05 message formats, but the Rooms and Rates component is REST/JSON. Messages must use Content-Type: text/xml; charset=utf-8 for SOAP calls, and UTF-8 encoding is required throughout — no exceptions for SOAP 1.2 or alternative protocols.

• Authentication. SOAP requests authenticate via a WS-Security (WSSE) UsernameToken in the SOAP header; REST endpoints use HTTP Basic Authentication. Credentials are issued at the PMS level, so one set of credentials can cover every property connected through that PMS, with a HotelCode distinguishing each property in the request payload.

• The mandatory first call. Every pmsXchange integration starts with Rooms and Rates — retrieving the room type and rate plan mapping SiteMinder has configured for a given property. This mapping underpins every subsequent availability, rate, and reservation operation, which is why it has to be certified first.

• Push-only for rates and availability. pmsXchange does not support a pull model for rates, availability, or restrictions. Once a PMS is connected, it becomes the system of record and pushes updates to SiteMinder — SiteMinder never polls the PMS for this data.

• Update cadence. SiteMinder expects delta updates in near real time (within roughly two minutes of a change occurring), not scheduled batch syncs. Full inventory flushes are reserved for initial setup or specific troubleshooting requests from SiteMinder support.

• Reservations delivery. PMS partners can implement either a PUSH or PULL model for receiving reservations, though PUSH is the recommended approach. If a PMS repeatedly fails to confirm receipt of a reservation, SiteMinder's timeout handling triggers a notification email to the property advising them to contact their PMS provider.

SiteConnect: For Contracted Booking Channels

SiteConnect is built for booking channels that hold a direct contractual relationship with individual properties. It's structurally the mirror image of pmsXchange from the channel's side: SiteMinder pushes availability, restrictions, and rates to the channel via SOAP, and the channel sends reservations back to SiteMinder in real time.

Channels implementing SiteConnect expose a single global endpoint that can serve every connected hotel, with a Security Header on each SOAP request authenticating the exchange. Because SiteMinder initiates the availability and restriction updates, the channel side needs to validate the incoming request credentials and respond correctly to OTA_HotelAvailNotifRQ messages with a confirmation or an error response.

Channels Plus: REST Access Without Direct Contracts

Channels Plus solves a different problem than SiteConnect. It's designed for booking channels that want to reach a broad set of SiteMinder-connected properties without negotiating a direct contract, billing arrangement, or manual onboarding with each one. Instead of SiteMinder pushing data to the channel, Channels Plus works on a pull ("shop") model — the channel queries SiteMinder on demand for the latest availability and pricing.

The core REST/JSON flow looks like this:

1. Get Properties — search for shoppable properties by location and date, returning content plus the best available rate for each match. This is the mandatory first call for every Channels Plus integration.

2. Get Property — retrieve full room rates and content for a specific property matching the guest's requested occupancy.

3. Lock Reservation — temporarily hold a room rate while the guest completes checkout.

4. Confirm Reservation — finalize a booking that's still within its lock window.

5. Update / Cancel Reservation — modify guest details (pricing changes require cancel-and-rebook) or cancel within the allowed window.

6. Get Reservations — retrieve bookings by date type (booked-on, check-in, or check-out) across a date range.

Authentication uses channel-level API credentials — an API ID and API key generated from SiteMinder's Partner Portal — passed on every request. SiteMinder is explicit that Channels Plus is a server-to-server API: credentials must never be exposed in front-end or client-side code. The Partner Portal also gives channels tools to discover properties, manage negotiated "deals" (special rates applied via a dealCode), and track billed reservations, and it enforces a rate limit of requests per five-minute window per channel.

SMX: Reservation Data for Applications

SMX is the read-access API for third-party applications that need reservation and property data without managing inventory themselves — think CRM platforms, guest experience tools, upsell engines, and revenue analytics products. RMS partners commonly pair SMX with pmsXchange: pmsXchange handles the rate and restriction push, while SMX supplies the reservation data layer the RMS needs to calculate pricing recommendations.

Direct Booking API: Powering Property Websites

For properties and hotel groups building their own booking engine, the Direct Booking API provides real-time availability, restrictions, rates, and property content so a hotel's own website — rather than a third-party channel — can sell rooms directly with live, accurate data.

The Partner Lifecycle: From Application to Go-Live

Every SiteMinder integration, regardless of which API you're building against, follows the same five-stage lifecycle.

1. Become a Partner. Apply through SiteMinder's partner program. Approval grants access to test accounts, full documentation, and shared sandbox credentials so development can start immediately — you don't need to wait for a dedicated test account to begin building.

2. Build. Develop against the sandbox environment. Both pmsXchange and Channels Plus publish Postman collections with pre-filled test credentials, which is the fastest way to validate request structure before writing integration code.

3. Certify. Complete SiteMinder's certification scenarios for each required component. Some components are mandatory (marked accordingly in the API reference) while others are strongly recommended but optional depending on your system's capabilities — for example, a PMS certifies either Per Day Pricing (PDP) or Occupancy Based Pricing (OBP) rate delivery, whichever matches its pricing model, and either Reservations PUSH or PULL.

4. Go Live. Connect your first production property and launch. At this stage SiteMinder's Partner Integrations team typically requests your endpoint URLs, credentials, and pricing model to provision a dedicated test account ahead of full production rollout.

5. Enhance. Expand the integration over time — adding optional components, supporting new API features, or extending coverage across more properties.

Integration Requirements Worth Planning Around

A few technical constraints show up repeatedly across SiteMinder's APIs and are worth designing for from day one:

• No pull model for PMS-sourced data. pmsXchange partners must push changes proactively; SiteMinder will not poll a PMS for updates. Your integration needs a reliable internal change-detection mechanism to catch every rate, availability, and restriction update as it happens.

• Delta updates, not full syncs. Sending only what changed — rather than re-sending full inventory on every update — is the expected pattern for both pmsXchange and SiteConnect. Full flushes are the exception, not the routine.

• Length-of-stay restrictions are check-in based. pmsXchange supports standard MinLOS/MaxLOS applied on the check-in date but not "stay-through" restrictions that apply when any part of a reservation touches a given date. Patterned length-of-stay requirements (e.g., stays must be exactly 7, 14, or 28 nights) aren't supported directly either — the workaround is modeling them as separate rate plans, each with its own MinLOS value.

• Credential scope varies by API. pmsXchange issues credentials at the PMS level (one set can cover multiple properties, distinguished by HotelCode), while Channels Plus issues them at the channel level via the Partner Portal. Design your credential storage and property-mapping logic around whichever scope applies to your integration type.

• Server-to-server only for REST APIs. Channels Plus API keys are explicitly not meant for client-side use. Any front-end booking flow needs a backend layer that holds credentials and proxies requests.

Choosing the Right API for Your System

If you're still unsure which API applies to your integration, this quick decision path covers most cases:

• Building or extending a PMS or RMS? → pmsXchange

• A booking channel with direct property contracts? → SiteConnect

• A booking channel without direct contracts, wanting broad reach across opted-in properties? → Channels Plus

• Building a CRM, analytics, or guest experience application? → SMX

• A property or hotel group building your own booking engine? → Direct Booking API

Some integrations span more than one API — an RMS combining pmsXchange and SMX is a common pattern, and it's worth mapping your full data requirements against all five before committing to an architecture.

Final Thoughts

SiteMinder's API surface is broad because the problems it solves are genuinely different depending on which side of the transaction you sit on — pushing inventory, pulling it on demand, reading reservation data, or powering a direct booking flow. Getting the API selection right at the start saves significant rework later, since pmsXchange, SiteConnect, and Channels Plus each carry distinct protocol, authentication, and data-flow requirements that shape how the rest of the integration gets built.

For teams building or maintaining PMS, channel manager, or OTA integrations — with SiteMinder or any other hotel distribution platform — getting the architecture, authentication flow, and certification scenarios right the first time is where most integration timelines either hold or slip.

Need help scoping or building a SiteMinder integration? Teenva AI & Digital Ventures builds API integrations and booking platform architecture for OTAs, TMCs, DMCs, and travel agencies. Reach out at sales@teenvaai.com or +91 9572020107.