Chat with our AI Assistant to get instant answers on APIs, troubleshooting, and integration steps.
Ask ✨
Ctrlk
Sandbox LoginPartner ContactsBecome a SiteMinder Partner
For the complete documentation index, see llms.txt. This page is also available as Markdown.
Beta

SM -> PMS

Receive real-time restriction updates from SiteMinder to keep your PMS synchronized.

This is a beta specification and subject to change. Reach out to our Ecosystem Team if you wish to develop to this API.

API: pmsXchange · Operation: Restrictions · Direction: SM → PMS · Method: Push

What is Restrictions (SM -> PMS)?

Restrictions (SM -> PMS) is a push notification method where SiteMinder sends restriction updates directly to your Property Management System (PMS). This integration ensures that booking rules configured on the SiteMinder Platform are automatically synchronized to the PMS, maintaining accurate restriction management across all connected systems.

To implement Restrictions (SM -> PMS), the PMS must certify for Restrictions (PMS -> SM).

Considerations

  • Asynchronous Processing: Due to high update volumes, your PMS must receive updates and queue them for offline processing rather than processing in real-time. This prevents blocking further updates from the PMSX application.

  • Message Volume: Each message covers a specific room rate code combination with up to 760 dates per message, depending on the hotel's configured update period.

  • Selective Restriction Delivery: SiteMinder only sends restriction types that your PMS supports, preventing unnecessary data transmission.

  • Code Mapping: Use invTypeCode and ratePlanCode values that match the codes returned from the PMS Room and Rates endpoint.

Authentication Requirements: The REST components of the pmsXchange API only support PMS-level authentication, which means using the same credentials across all properties. If you’re currently using hotel-level authentication (credentials per property), we recommend switching to PMS-level to ensure compatibility with the REST endpoints.

Hotel Room Rate Update (Restrictions)

post

Endpoint to receive and process hotel room rate restrictions

Authorizations
AuthorizationstringRequired
Path parameters
hotelCodestringRequired

Hotel identifier code

pmsCodestringRequired

PMSX partner code

Header parameters
X-SM-TRACE-TOKENstringRequired

The unique identifier of the request (UUID), this traceToken is logged with this request.

Example: 8bf21e96-e6c7-4bf9-a377-a5763e053538
Body
invTypeCodestringRequired

Inventory type code

Example: ABC
ratePlanCodestringRequired

Rate plan code

Example: CBA
Responses
200

Restrictions Update received

post/pmses/{pmsCode}/hotels/{hotelCode}/restrictions/v1
POST /pmses/{pmsCode}/hotels/{hotelCode}/restrictions/v1 HTTP/1.1
Host: pmsx-partner.com
Authorization: Basic username:password
X-SM-TRACE-TOKEN: 8bf21e96-e6c7-4bf9-a377-a5763e053538
Content-Type: application/json
Accept: */*
Content-Length: 165

{
  "invTypeCode": "ABC",
  "ratePlanCode": "CBA",
  "restrictions": [
    {
      "date": "2025-01-01",
      "minLOS": 2,
      "maxLOS": 7,
      "close": false,
      "closeToArrival": false,
      "closeToDeparture": false
    }
  ]
}
No content

Common Questions

Why must I queue updates for offline processing instead of processing them immediately?

Due to the high volume of restriction updates, processing them synchronously would block SiteMinder from sending subsequent updates. Your PMS should:

  1. Receive the update and return 200 OK immediately

  2. Queue the update for asynchronous processing

  3. Process the queued updates offline without blocking new incoming requests

This ensures continuous data flow and prevents update backlogs.

What happens if my PMS doesn't support a specific restriction type?

SiteMinder only sends restriction types that your PMS supports. During integration setup, you specify which restriction types your PMS can handle. Unsupported restriction types won't be included in the update messages, reducing unnecessary data transmission and processing.

How many dates can be included in a single update message?

Each message can contain up to 760 dates for a specific room rate code combination. The actual number depends on the update period configured by the hotel. Each date in the array represents a separate day's restrictions.

How should I handle the Retry-After header in 429 responses?

When your PMS returns a 429 (Too Many Requests) response, include the Retry-After header with the number of seconds SiteMinder should wait before retrying. This allows you to implement rate limiting and back-pressure when your system is under high load.

Example: Retry-After: 60 tells SiteMinder to wait 60 seconds before sending the next update.

sparkles

Still have questions?

Use the Ask button at the top of the page to chat with our AI assistant — it can help you navigate the guide, understand requirements, and troubleshoot issues.

If you need more support, visit Integration Support.

Last updated

Was this helpful?