SM -> PMS

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

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

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

basicAuth

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

application/json

invTypeCodestringRequired

Inventory type code

Example: ABC

ratePlanCodestringRequired

Rate plan code

Example: CBA

Responses

200

Restrictions Update received

400

Bad request

application/json

401

Unauthorized

application/json

403

Access Denied

application/json

404

Not Found

application/json

429

Too Many Requests

500

Internal server error

application/json

503

Service Unavailable

application/json

post

/pmses/{pmsCode}/hotels/{hotelCode}/restrictions

HTTPcURLJavaScriptPython

POST /pmses/{pmsCode}/hotels/{hotelCode}/restrictions 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.

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.