# Integration Requirements 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 Policy 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](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 `` * Requests include SOAP Security Header (see [Security](#security)) * Responses use empty SOAP Header: `` * Content-Type: `text/xml; charset=utf-8` (no other Content-Types accepted) * Character Encoding: UTF-8 exclusively {% hint style="danger" %} SOAP 1.2, REST, or other protocols are **not supported**. Systems using alternative protocols must be modified to use SOAP 1.1. {% endhint %} *** ## 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 {% hint style="success" %} **Security Header Format**: See individual API component pages for complete examples. {% endhint %} ### 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` {% hint style="warning" %} **Restricted Characters**: Do **NOT** use the characters `<` `>` `&` `"` `'` in usernames or passwords as they cause XML parsing issues. {% endhint %} ### 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. {% hint style="success" %} All SiteMinder requests originate from **port 443** (HTTPS). {% endhint %} *** ## 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` {% hint style="warning" %} **Critical for Support**: Highly unique EchoTokens enable efficient troubleshooting. Sequential numbers or timestamp-only values slow issue resolution significantly. {% endhint %} ### 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 ``` {% hint style="success" %} **Best Practice**: Use UTC timestamps (with `Z` suffix) to eliminate timezone confusion and simplify troubleshooting. {% endhint %} ### 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**: {% code overflow="wrap" %} ```xml Single bed for single occupancy.Best Available Rate. ``` {% endcode %} **Incorrect Format**: ```xml ``` ### 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`) {% hint style="success" %} If architectural constraints require separate endpoints, inform Partner Integrations during setup. SiteMinder can accommodate up to two URIs. {% endhint %} ### 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](https://developer.siteminder.com/siteminder-apis/integration-process) team to migrate to the global endpoint for simplified routing and improved reliability. **Endpoint Details**: See [Reservations](https://developer.siteminder.com/siteminder-apis/channels/introduction/siteconnect/api-reference/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` {% hint style="warning" %} **Important**: Choose a logical, scalable `HotelCode` format upfront. Changing codes post-production requires coordination and causes temporary service disruption. {% endhint %} ### RequestorID / Channel Code **Definition**: Unique identifier for your booking channel integration. **Usage**: * **SOAP Messages**: `` **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**) {% hint style="danger" %} **Critical**: The 20-second timeout is a failsafe mechanism, not a performance goal. Responses consistently approaching 10+ seconds indicate performance issues requiring immediate attention. {% endhint %} **Response Behaviour**: * Respond with `` or `` 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 {% hint style="success" %} **Best Practice**: Over-provision capacity by 50% to handle unexpected spikes during peak booking periods and simultaneous property onboarding. {% endhint %} ### 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](https://developer.siteminder.com/siteminder-apis/channels/introduction/siteconnect/technical-guide/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) {% hint style="warning" %} **Partner Responsibility**: Educate hotels using your channel about timezone configuration requirements. Timezone mismatches cause availability conflicts and booking errors. {% endhint %} **Implementation Best Practices**: 1. Convert all datetimes to UTC internally for consistent processing 2. Display times in hotel's local timezone in user interfaces 3. Store original timezone offset with temporal data 4. Handle Daylight Saving Time (DST) transitions correctly 5. 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](https://developer.siteminder.com/siteminder-apis/channels/introduction/siteconnect/testing-and-certification)) * [ ] Postman collections executed successfully * [ ] Component-specific requirements met (see [API Reference](https://developer.siteminder.com/siteminder-apis/channels/introduction/siteconnect/api-reference)) * [ ] HotelCode format defined and documented {% hint style="success" icon="sparkles" %} ## Still have questions? Use the :gitbook-assistant: **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](/integration-support/integration-support.md). {% endhint %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://developer.siteminder.com/siteconnect-api/guides/integration-requirements.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.