Asynchronous APIs

Table 18-1 Asynchronous APIs

Best Practice	What to avoid and why
Always consider and adhere to the recommended and optimal payload size of 200 entries within the item array when updating rates or performing other POST data in Asynchronous APIs.	Attempting to update data to OPERA Cloud immediately after its creation using asynchronous APIs without considering the payload size (assuming no restrictions on the update process). While the operations that POST data to OPERA Cloud (including rate updates) operate on a first-come, first-served basis, allowing updates right after creation, the primary limitation lies in the payload size. Ignoring this guideline may lead to an anti-pattern where updates are made without proper consideration, potentially causing performance issues and compromising the reliability of the API.
As a revenue management system, use the Asynchronous APIs for actions like fetching a year’s worth of reservations. For more detailed instructions for revenue management systems, consult the Implementation Guide.	Using synchronous REST APIs to fetch bulk data or update bulk data needed for revenue management systems. This can impact performance.
Asynchronous APIs allow a maximum of 150 requests per minute for each application, encompassing POST, HEAD, and GET requests. Take this into account when deciding the polling frequency for HEAD requests. For more information on limits, see Limits.	Calling Asynchronous APIs as if there were no rate limit.
When sending a POST request, allow a waiting period of at least 1-2 minutes before initiating the HEAD request.	Sending HEAD very quickly after sending POST. Given the nature of the Asynchronous APIs, it is unlikely that the request in the POST will have been processed in so short an interval. This will not speed up the Asynchronous APIs, and it will be billable (for integration partners) and will use up the rate limit on the Asynchronous APIs.
When sending a HEAD request, wait for the HTTP status 201 Created response before proceeding with the GET request. If the HEAD request gives an HTTP Status 200 OK response, allow another 1-2 minutes before resending the HEAD request. In other words, if the HEAD response does not return a 201 Created response with a header location, the job probably has not finished yet. Allow another 1-2 minutes before sending the GET request. After receiving an HTTP status 201 Created, you can proceed with the GET request.	Calling GET immediately after HEAD or calling it repeatedly. The 201 Created status means that the request has been processed and the results are available. Until this status is returned in the HEAD request, calling GET will simply use up the rate limit on the Asynchronous APIs.
Be prepared to call HEAD multiple times, depending on the volume of data being processed.	Calling HEAD only once and assuming the processing has finished. The Asynchronous APIs process large amounts of data, which takes time.
Ensure that code consuming responses from Oracle Hospitality Property APIs treats header keys as case insensitive.	Code that breaks if the casing of response values changes.