Integration Requirements

Technical standards, security protocols, and compliance requirements that apply across all SiteConnect API components.

This page defines the technical standards, security protocols, and operational requirements that apply across all SiteConnect API components. These requirements ensure reliable, secure, and efficient connectivity between your booking channel and the SiteMinder platform.

Compliance and Standards

Compliance Policy

Mandatory Compliance: All integration partners must adhere to these requirements. Due to the growing number of partner integrations, SiteMinder can no longer accommodate exceptions.

Non-Compliance Timeline:

Partners have 90 days to remediate non-compliance issues after notification
Failure to comply may result in interface deactivation
Critical issues affecting production stability may result in immediate temporary suspension

Technical Foundation

Open Travel Alliance (OTA) Specifications

The SiteConnect API is built on Open Travel Alliance (OTA) version 2010A specifications. Integration developers should be familiar with these standards, available at http://www.opentravel.org. While this documentation is comprehensive, the OTA specifications provide additional context for complex scenarios and edge cases.

SOAP Protocol Requirements

SiteConnect exclusively supports SOAP 1.1.

Message Structure Standards:

All messages follow SOAP envelope structure
OTA message must be within <SOAP-ENV:Body>
Requests include SOAP Security Header (see Security)
Responses use empty SOAP Header: <SOAP-ENV:Header/>
Content-Type: text/xml; charset=utf-8 (no other Content-Types accepted)
Character Encoding: UTF-8 exclusively

SOAP 1.2, REST, or other protocols are not supported. Systems using alternative protocols must be modified to use SOAP 1.1.

Security

Transport Layer Security

Minimum Standard: TLS 1.2 or higher

Requirements:

All communication must use HTTPS over port 443
HTTP (non-secure) connections are prohibited
Production endpoints must use valid SSL certificates
Self-signed certificates are not supported

Authentication

Method: WS-Security (WSSE) UsernameToken (username and password)

All SOAP requests include a Security Header with credentials transmitted as plain text within the HTTPS encrypted channel.

Authentication Scope:

One set of credentials covers all properties in your integration
Same credentials used for all API components
Your endpoint validates credentials on every request
Invalid credentials return SOAP fault with error code

Security Header Format: See individual API component pages for complete examples.

Strong Password Policy

Minimum Requirements:

At least 12 characters long
Mix of uppercase and lowercase letters
At least one number
At least one special character (e.g., ! @ # ? ])

Example Strong Password: MyP@ssw0rd2024!Secure

Restricted Characters: Do NOT use the characters < > & " ' in usernames or passwords as they cause XML parsing issues.

IP Whitelisting (Optional)

Partners may whitelist our IPs for additional security.

Pre-Production IPs:

52.13.134.140
34.213.128.113
35.164.250.223

Production IPs: Provided by Partner Integrations team during go-live.

All SiteMinder requests originate from port 443 (HTTPS).

Message Standards

EchoToken (Request Identifier)

Purpose: Unique identifier for request/response correlation and troubleshooting.

Requirements:

Must be unique for every request
Both request and response include the same EchoToken
Used for log searching and debugging across environments
Format: UUID with 8-4-4-4-12 pattern

Example: ed8835ff-6198-4f38-b589-3058397f677c

Critical for Support: Highly unique EchoTokens enable efficient troubleshooting. Sequential numbers or timestamp-only values slow issue resolution significantly.

TimeStamp Format

Standard: ISO 8601 Date and Time format

Accepted Formats:

UTC Time (recommended):

2024-11-19T13:15:30Z

Local Time with Offset:

2024-11-19T08:15:30-05:00

Best Practice: Use UTC timestamps (with Z suffix) to eliminate timezone confusion and simplify troubleshooting.

XML Formatting Requirements

Production Requirement: Minified XML (single line, no whitespace)

All SOAP XML messages sent to SiteMinder must be minified, removing line breaks, newlines, and unnecessary whitespace. Single-line XML enables support teams to efficiently extract complete messages from logs using text searches.

Correct Format:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-ENV:Header/><SOAP-ENV:Body><OTA_HotelAvailRS xmlns="http://www.opentravel.org/OTA/2003/05" EchoToken="ed8835ff-6198-4f38-b589-3058397f677c" TimeStamp="2024-07-06T15:27:41Z" Version="1.0"><Success/><RoomStays><RoomStay><RoomTypes><RoomType RoomTypeCode="SGL"><RoomDescription Name="Single Room"><Text>Single bed for single occupancy.</Text></RoomDescription><Occupancy AgeQualifyingCode="10" MaxOccupancy="2"/></RoomType></RoomTypes><RatePlans><RatePlan RatePlanCode="BAR"><RatePlanDescription Name="Best Available Rate"><Text>Best Available Rate.</Text></RatePlanDescription></RatePlan></RatePlans></RoomStay></RoomStays></OTA_HotelAvailRS></SOAP-ENV:Body></SOAP-ENV:Envelope>

Incorrect Format:

<SOAP-ENV:Envelope
	xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
	<SOAP-ENV:Header/>
	<SOAP-ENV:Body>
		<OTA_HotelAvailRS
			xmlns="http://www.opentravel.org/OTA/2003/05" EchoToken="ed8835ff-6198-4f38-b589-3058397f677c" TimeStamp="2024-07-06T15:27:41Z" Version="1.0">
			<Success/>
			<RoomStays>
				<!-- ... other elements and attributes have been omitted for brevity ... -->
			</RoomStays>
		</OTA_HotelAvailRS>
	</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

API Version and Namespace

API Version: 1.0

All OTA messages must include Version="1.0" attribute in the root element.

XML Namespace: http://www.opentravel.org/OTA/2003/05

All OTA messages must declare this namespace using the xmlns attribute in the root element.

Configuration

Endpoint Requirements

Your Endpoint Standards (Partner Provides):

Mandatory Requirements:

Must use registered domain name (direct IP addresses not supported)
Must be accessible via HTTPS on port 443
Must accept SOAP 1.1 messages with proper Content-Type

Configuration Options:

Option 1 - Single Endpoint (Recommended):

One URI handles all message types (OTA_HotelAvailRQ, OTA_HotelAvailNotifRQ, OTA_HotelRateAmountNotifRQ)
Simplifies configuration and maintenance

Option 2 - Dual Endpoints:

Separate endpoints for different operations:
- Endpoint 1: Rooms and Rates (OTA_HotelAvailRQ)
- Endpoint 2: Inventory Updates (OTA_HotelAvailNotifRQ, OTA_HotelRateAmountNotifRQ)

If architectural constraints require separate endpoints, inform Partner Integrations during setup. SiteMinder can accommodate up to two URIs.

Reservation Delivery Endpoint

Production Endpoint Update: SiteMinder now uses a single global endpoint for all reservation delivery, replacing the previous regional endpoint model (APAC and EMEA/AMERS). If your integration currently uses region-specific endpoints, please contact the Partner Integrations team to migrate to the global endpoint for simplified routing and improved reliability.

Endpoint Details: See Reservations for complete endpoint specifications.

Property Identification (HotelCode)

Definition: Unique identifier assigned by your booking channel for each property.

Requirements:

Must be unique per property per channel
Used consistently across all API components
Cannot be changed without re-mapping (causes service disruption)

Format: Alphanumeric string (your choice)

Examples: PROP12345, LONDON001, HTL987654

Important: Choose a logical, scalable HotelCode format upfront. Changing codes post-production requires coordination and causes temporary service disruption.

RequestorID / Channel Code

Definition: Unique identifier for your booking channel integration.

Usage:

SOAP Messages: <RequestorID Type="22" ID="ABC"/>

Requirements:

Must match across all reservation messages
Case-sensitive
Provided by SiteMinder during setup

Performance and Reliability

Response Time Requirements

Target Performance (per request):

Ideal: Sub-1-second response
Acceptable: 1-2 seconds average
Timeout: 20 seconds (failsafe, not a target)

Critical: The 20-second timeout is a failsafe mechanism, not a performance goal. Responses consistently approaching 10+ seconds indicate performance issues requiring immediate attention.

Response Behaviour:

Respond with <Success/> or <Errors> immediately
Acknowledge receipt promptly
Process asynchronously if downstream operations take time
Do not delay HTTP response while performing internal processing

Scalability Expectations

Data Volume Considerations:

Initial bulk loads: Up to 750 days of inventory data
Ongoing updates: Minimum 365 days from current date (configurable)
Multiple concurrent property updates
Peak periods during new property go-lives and seasonal changes

Testing Requirements:

Test with production-scale data volumes
Simulate concurrent property updates
Verify sustained load performance
Test recovery from failures

Best Practice: Over-provision capacity by 50% to handle unexpected spikes during peak booking periods and simultaneous property onboarding.

Error Handling

Mandatory Capabilities:

Your application must implement:

1. Robust Error Detection

Validate all requests against OTA schema
Detect authentication failures immediately
Identify malformed XML and missing required fields
Return proper SOAP faults with appropriate error codes

2. Queuing Mechanism

Queue failed updates for retry
Persist queue across application restarts
Prevent duplicate processing
Monitor queue depth and age

3. Retry Strategy

Implement exponential backoff for transient errors
Distinguish permanent vs. temporary failures
Define maximum retry attempts
Establish escalation path for persistent failures

Recommended Retry Pattern:

Attempt 1: Immediate (0 seconds)
Attempt 2: 5 seconds
Attempt 3: 15 seconds
Attempt 4: 30 seconds
Attempt 5: 60 seconds
After 5 attempts: Alert + manual intervention

Detailed Guidance: See Error Handling for complete specifications and error code reference.

Timezone Handling

Hotel Timezone Configuration:

Hotels configure their local timezone in SiteMinder Channel Manager
Availability, Restrictions, and Rates reflect hotel's local timezone
Your system must respect these timezone settings when processing updates

Server Timestamp Standards:

EMEA region: Server timestamps in GMT
APAC region: Server timestamps in AEST/AEDT (Australian Eastern Time)

Partner Responsibility: Educate hotels using your channel about timezone configuration requirements. Timezone mismatches cause availability conflicts and booking errors.

Implementation Best Practices:

Convert all datetimes to UTC internally for consistent processing
Display times in hotel's local timezone in user interfaces
Store original timezone offset with temporal data
Handle Daylight Saving Time (DST) transitions correctly
Validate date ranges respect timezone boundaries

Pre-Production Checklist

Before requesting production access, verify all requirements are met:

Security & Configuration

All endpoints use HTTPS with valid certificates (not self-signed)
Authentication credentials meet strong password policy (12+ characters)
Endpoints use registered domain names (no direct IPs)
TLS 1.2 or higher enabled

Message Standards

EchoTokens are highly unique (UUID/GUID format recommended)
XML output is minified (single line, no whitespace)
TimeStamps use ISO 8601 format (UTC recommended)
Content-Type is text/xml; charset=utf-8
API Version set to 1.0 in all messages
XML Namespace correctly declared

Performance & Reliability

Response times meet targets (<2 seconds typical)
Error handling with queue and retry implemented
Load testing completed with production data volumes (up to 750 days)
Failover and recovery scenarios tested
Timezone handling implemented correctly

Functional Requirements

All mandatory test scenarios passed (see Testing and Certification)
Postman collections executed successfully
Component-specific requirements met (see API Reference)
HotelCode format defined and documented

Questions? Contact your Partner Integrations representative. They're here to ensure your integration success.

Last updated 2 days ago

Was this helpful?