API Endpoints

Below is a list of required endpoints for a successful integration. Each endpoint has specific use cases for caching, retrieving detailed data, and supporting specific booking functionalities.

Retrieve Suppliers

GET/suppliers: Use this endpoint to temporarily store data in your system's cache, enabling faster access and improved performance compared to retrieving it directly from Travel Curious or the partner system.

GET/suppliers/{supplier_id}: Use to retrieve specific supplier details and avoid unnecessary load on the bulk endpoint.

Retrieve Products

GET/suppliers/{supplier_id}/products: Use this endpoint to temporarily store data in your system's cache, enabling faster access and improved performance compared to retrieving it directly from Travel Curious or the partner system.

GET/suppliers/{supplier_id}/products/{product_id}: Use to get specific product details. This should be the endpoint called instead of the bulk/list call to avoid unnecessary load

Retrieve Rates

GET/suppliers/{supplier_id}/products/{product_id}/rates: Use this endpoint to temporarily store data in your system's cache, enabling faster access and improved performance compared to retrieving it directly from Travel Curious or the partner system.

GET/suppliers/{supplier_id}/products/{product_id}/rates/{rate_id}: Use to get specific rate details. This should be the endpoint called instead of the bulk/list call to avoid unnecessary load

Pricing & Availability

GET/suppliers/{supplier_id}/products/{product_id}/pricing/schedule: Retrieves pricing data. For specific rate details, we recommend adding the rate_id in the request so you can get the response by the rate.

GET/suppliers/{supplier_id}/products/{product_id}/availabilities: Utilise this endpoint with start and end dates for range data. Use this endpoint to temporarily store data in your system's cache, enabling faster access and improved performance compared to retrieving it directly from Travel Curious or the partner system.

GET/suppliers/{supplier_id}/products/{product_id}/availability: Use for last-minute checks, especially with low inventory. This will avoid a hold or booking failure later. rate_id should be used in this kind of request.

Hold & Booking

POST/holds: Use to acquire a hold. Holds will become required in the specifications in the near future.

GET/holds/{hold_id}: Using the hold_id you can query this endpoint and get the same transaction details returned in the POST/holds call.

DELETE/holds/{hold_id}: As a best practice process, we recommend to use this endpoint to release the hold when no longer needed. This will release the inventory and make it bookable again instead of waiting for it to be automatically released after the holdable time is reached.

POST/bookings: Confirmation of booking after the hold was placed so the details of the booking cannot be modified from the hold, if different it will cause the booking to fail, even if the requested product is available.

GET/bookings/{booking_id}: By querying this endpoint with the booking_id you will get the same transaction details returned in the POST/booking call

• When you, the Reseller supports 202 responses they need to send HTTP GET booking requests periodically for the completion status of the job. The response from said API will inform the current status of the booking operation

PUT//bookings/cancel/{booking_id}: To cancel a booking, the booking_id is required. Please note that some suppliers do not allow cancellations initiated by the customer or by you, the Reseller, through the API. For these suppliers, products or rates are set with cancelable = false.