10 Limits

To ensure operational efficiency of hotel customers, various limits are in effect.

Number of Applications

The maximum number of applications that can be registered in the OHIP Developer portal is 100.

Streaming

Only One Consuming Client

Only one client can be connected to consume events from a single chain in a single gateway on a single application key.

To create a scalable consuming architecture, see Streaming Best Practices.

Consuming Limits

It is expected that streaming consumers remain connected at all times. In the event of a disconnection, it is vital that the consumer connects to the WebSocket at least once every 24 hours. If not, then you must send the optional "offset" input parameter together with the value of the last offset you received.

Ensure there is a minimum of 5000 ms (5 seconds) between sending the "complete" message to close one WebSocket connection and sending the next "subscribe" message to reopen a WebSocket connection.

For more information on consuming limits, see Streaming Best Practices.

Headers

The total size of all HTTP headers is 8KB. This includes the oAuth token, application key, x-request-id, and all other headers.

API Throttling

To ensure stable and reliable service for all customers, the Hospitality Integration Platform enforces limits on the rate of incoming API requests.

Current limits:
  • Up to 50 requests per second are allowed.
  • A short-term burst of up to 100 requests may be permitted.

If your integration exceeds the standard rate limit, additional requests within that second may be automatically delayed. Each request above the limit will experience a small, additional delay, helping to spread out the traffic and avoid overwhelming the platform.

If your system sends a very high number of requests in a short burst that exceeds the burst threshold, requests beyond this limit may be immediately rejected with an HTTP 429 ("Too Many Requests") response.

These limits are designed to protect ongoing hotel operations and to ensure all customers receive reliable service. Oracle may adjust these thresholds as needed to maintain service quality and will provide advance notification of changes whenever possible.

If you are frequently hitting the throttling limit, consider the following:

  • For Shop and Book related calls, consider Distribution APIs (see Oracle Hospitality Distribution APIs for more information).

  • Retrieve more coarse grained data in a single call rather than performing filtering in the client.

  • Reduce the frequency of calls.

  • Cache data that changes infrequently, such as Lists of Values.

  • Review the API release notes for new operations that could reduce the frequency of API calls (for example, asynchronous (jobbed) operations).

  • Consider the Streaming API as an alternative to the Polling API (pull).

Requests per Second

In the Integration Processor API, the following operations permit a maximum of 300 requests per minute per gateway:

  • getBusinessEvents

  • getBusinessEventsByExternalSystem

If a larger amount of events is required (than allowed by the limits), consider the Streaming API (push).

Asynchronous APIs allow a maximum of 100 requests per minute for POST, 300 requests per minute for HEAD, and 300 requests per minute for GET for each environment.

oAuth Token Lifetime

Our recommendation is to request a token when the current token will expire in 1 minute and implement code that caches and automatically renews the token (when the token's lifetime is down to 1 minute) and stores it securely. Code that makes API calls can then use the cached token and be assured it is always valid.

Ensure that the code looks at the "exp" attribute of the oAuth token to determine when the token will expire.

Request Body Size

The maximum request body size is 100KB.

The following endpoints allow a maximum request body size of 2MB:

  • In the Property API Price Availability Rate Async, the operation:

    • postRestrictionsProcess

  • In the Property API Block, the operations:

    • postRoomingList

    • postSubAllocation

    • putBlockAllocation

  • In the Property API Reservation, the operations:

    • postReservation

    • postReservationByBlock

  • In the Property API Rate Plan Asynchronous Service, the operation:

    • startSetDailyRatePlanSchedulesProcess

  • In the Property API Inventory Asynchronous, the operation:

    • postSellLimitsProcess

  • In the Property API Content Service, the operations:

    • emailFolioReport

    • setCustomizedLetter

  • In the Property API OPI Token Exchange Service, the operation:

    • openPaymentTokenExchange

The following endpoints allow a maximum request body size of 14MB:

  • In the Property API Content Service, the operations:

    • uploadFileAttachment

    • uploadImage

Pagination Limits

Most Property APIs are paginated, meaning they return only one page of data at a time. The maximum size of the page is defined by limits documented both in the API specifications and in Property REST API Get Query Parameter Limits.

Asynchronous APIs

Asynchronous APIs allow a maximum of 250 requests per minute for each application per environment for POST requests.

Since they process data in bulk, the Asynchronous APIs have additional restrictions. A full matrix of these are available in Types and Usage Recommendations, but these are repeated below:

Identical Requests

To avoid duplicate requests, every identical request (employing the same query parameters) necessitates a mandatory 30-minute interval between submissions. Note that this limit applies regardless of whether the POST, HEAD, and GET cycle has been completed.

Operations that allow data to be queried by date are subject to additional restrictions on how frequently the operation can be used:

  • In the Property API Block Reservation Asynchronous, identical requests to the operation startBlockAllocationSummaryProcess (when used with startLastModifiedDate/endLastModifiedDate) must be spaced 3 hours apart. Note that this limit only applies to identical POST requests made without completing the entire POST, HEAD, and GET cycle.

  • In the Property API Reservation Asynchronous, in the operation startReservationsDailySummaryProcess, identical requests to the operation startBlockAllocationSummaryProcess (when used with startLastModifiedDate/endLastModifiedDate) must be spaced 3 hours apart. Note that this limit only applies to identical POST requests made without completing the entire POST, HEAD, and GET cycle.

Maximum Frequency
Operations that allow data to be queried by date are subject to additional restrictions on how frequently the operation can be used:

  • In the Property API Block Reservation Asynchronous, the operation startBlockAllocationSummaryProcess is used with startLastModifiedDate/endLastModifiedDate.

Maximum Date Ranges

Synchronous APIs

Several Property APIs have a maximum date range. These restrictions are listed in the API specifications as well as in Property REST API Get Query Parameter Limits.

Asynchronous APIs

The maximum range of start and end dates submitted to the following Asynchronous APIs is limited:

  • In the Property API Inventory Asynchronous, the operation startRevenueInventoryStatisticsProcess has a maximum date range of 400 days. For OPERA version specific restrictions, refer to Types and Usage Recommendations.

  • In the Property API Block Reservation Asynchronous, the operation startBlockAllocationSummaryProcess has a maximum date range of 94 days.  However, when requesting data with startLastModifiedDate/endLastModifiedDate, the maximum date range allowed per request is 3 days.

  • In the Property API Reservation Asynchronous, the operation startReservationsDailySummaryProcess has a maximum date range of 94 days.

  • In the Property API Rate Plan Asynchronous Service, the operation startSetDailyRatePlanSchedulesProcess allows rate plans to be defined for up to 365 days.

Length Restrictions and Multi-byte Characters

Many attributes in APIs have length restrictions, such as the below example from the operation postReservation where the "addressLine" property is limited to 80 characters.
"addressLine": {
"description": "When the address is unformatted (FormattedInd=\"false\") these lines 
will contain free form address details. When the address is formatted and street number 
and street name must be sent independently, the street number will be sent using 
StreetNmbr, and the street name will be sent in the first AddressLine occurrence.",
    "type": "array",
    "maxItems": 4,
    "items": {
      "type": "string",
      "minLength": 0,
      "maxLength": 80
  }
}

The 80 characters of this restriction implies 80 ASCII characters. Many UTF-8 characters are multi-byte. A multi-byte character takes up more than one ASCII character, so fewer than 80 multi-byte characters will fit into the "addressLine" field.

Consumers sending multi-byte characters must ensure the ASCII equivalent length of the data does not exceed the published length restrictions.