API Overview

Everything you must know to start connecting with Rezdy API

RESTful API

The Rezdy API is a REST (REpresentational STate) based API which allows you to read and possibly write resources linked to your Rezdy account. The API makes use of the HTTP verbs to determine the type of request, for example:

GET      /products            Lists all products in your account.
GET      /products/P123456    Reads the product with code P123456.
POST     /bookings             Creates a new booking.
DELETE   /customers/12345      Deletes customer with Id 12345.

Please note that not every resource supports all operations. Please check the complete list of operations on our live client.

 

Media Types

The Rezdy API supports both XML and JSON formats. You must include both Accept and Content-Type headers to your requests, they will determine which format is used to parse and respond to your request.

UTF-8 should be used for all content encoding.

Content-Type: application/json; charset=UTF-8
Accept: application/json

Versioning

Rezdy API is versioned, and you must include the version in the URL you’re calling.
Please note our API is actively updated. Non-breaking changes are released without the version being updated. Version will be v1 until major changes are released. Please check the changelog for details

https://api.rezdy.com/v1/products

You can also use /latest/ to automatically use the latest available version:

https://api.rezdy.com/latest/products

Environments

We provide a test environment so you can test your integration and make sure it’s ready before connecting with the Production server. These environments are completely disconnected, accounts are not shared so you will have to create a new account and generate a new API key on our Test server in order to use it. All requests must use HTTPS, the API is not available on non-SSL ports. When testing an Agent integration, it is easier to only use the production environment, and book Test products from our Demo suppliers.

EnvironmentApplication URLAPI URLAPI Documentation URL
Testhttps://test.rezdy.comhttps://api-test.rezdy.comhttps://apidocs-test.rezdy.com
Productionhttps://app.rezdy.comhttps://api.rezdy.comhttps://apidocs.rezdy.com

Please note that on the Test environment, you will not have access to online booking forms. They will return a 404 unless you add the test server IP to your local hosts file. We usually release new updates to the test server one week before they’re applied to production, so there may be differences. Check the changelog for details.

Authentication

All API calls require a valid API Key. It must be passed as a query parameter to all requests, using the following format:

https://api.rezdy.com/v1/products?apiKey=XXXXXXXXXXXXXXXXXXXX

You can generate and revoke your API key by logging into your Rezdy account.

Response format

All responses will contain a “requestStatus” element. That element will tell you if your request was successful, and can contain error and warning messages.

Successful request:
{
 "requestStatus": {
  "success": true,
  "version": "v1"
 }
}
Request with error:
{
 "requestStatus": {
  "success": false,
  "error": {
   "errorCode": "6",
   "errorMessage": "Invalid API Key"
  }
 }
}

Date format

We provide 2 date formats for Availability and Booking dates/times. The first is ISO8601 format and attributes are usually called startTime/endTime. The second is the supplier’s localized time based on their Timezone and attributes are usually called startTimeLocal/endTimeLocal.

ISO8601 format

If you use ISO8601 format, you have to convert times to the supplier’s timezone when you want to display dates and times. For example, if a supplier runs a tour on 30 Oct 2014 at 9:00 AM in the “Sydney/Australia” timezone, time in ISO8601 format returned by the API will be

2014-10-29T22:00:00Z

That’s because 2014-10-29T22:00:00Z is the same time than 2014-10-30T09:00:00+11:00. You can send any of these formats in your API calls and they’re both valid and both represent the same timestamp. You can retrieve the supplier’s timezone in GET /products calls (Product.timezone). Please be mindful of Daylight Savings Time when converting timestamps. You should always use the proper timezone (I.e. “Australia/Sydney”) instead of the time offset (+10:00) because the latter can vary during the year (I.e. Sydney is +10:00 in winter and +11:00 in summer)

Local format

If you use the Localized format, you will receive and return

2014-10-30 09:00:00

You don’t need to do any Timezone conversion when using the Localized format.

Pagination

Requests that return multiple items are paginated to 100 items by default. You can control pagination by using the offset (default:0) and limit (default: 100) query parameters. The custom limit may not exceed 100.

GET /products?offset=0&limit=20
GET /products?offset=20&limit=20
GET /products?offset=40&limit=20

Usage throttling

API use is restricted to 100 calls per minute per API Key. We reserve the right to alter this limit based on usage patterns. Rezdy certified partners can get a higher customized limit. If you reach your limit, you will receive an HTTP Status 406 response with message “Too Many Requests”

Caching

To provide the best experience to your customers and avoid hitting the rate limits, you should implement some form of caching on your end rather than calling the Rezdy API for each request. For example a typical browsing + booking process could follow this caching strategy:

Customer action on your websiteRezdy API CallCaching recommendation
Browse product 1GET /products/{product1}Cache for 24+ hours
Check product 1 availabilityGET /availabilityCache for 24 hours
Browse product 2GET /products/{product2}Cache for 24+ hours
Check product 2 availabilityGET /availabilityCache for 24 hours
Add product 2 to shopping cart – Starts checkoutGET /availabilityNo Cache – confirms product is still available
Completes checkoutPOST /bookingsNo Cache

Error codes

The following error codes can be returned in the requestStatus object

Error codeMeaningDetails
1UNKNOWNIndicates an unknown error.
2NO_IMPLEMENTATIONIndicates that the target business system has no implementation for the intended request.
3BIZ_RULEIndicates that the XML message has passed a low-level validation check, but that the business rules for the request message were not met.
4AUTHENTICATIONIndicates the message lacks adequate security credentials
5AUTHENTICATION_TIMEOUTIndicates that the security credentials in the message have expired
6AUTHORIZATIONIndicates the message lacks adequate security credentials
7PROTOCOL_VIOLATIONIndicates that a request was sent within a message exchange that does not align to the message
8TRANSACTION_MODELIndicates that the target business system does not support the intended transaction-oriented operation
9AUTHENTICAL_MODELIndicates the type of authentication requested is not recognized
10MISSING_FIELDIndicates that an element or attribute that is required in by the schema (or required by agreement between trading partners) is missing from the message

API Limitations

Our API is actively updated, we regularly add new endpoints and features to support more use cases. There are however current limitations:

  • You cannot yet update bookings through the API
  • Rental products and products with a price per duration cannot be booked through the API yet
  • Shuttle and Transfer products with return cannot be booked through the API yet (Transfer product types without return can be booked)

Availability

Our applications and API availability can be view on our current and historical server status.

We have a general maintenance window on Mondays from 18:00 to 22:00 Sydney time (AEST), when the servers can have a few minutes unavailability while we push new releases. Downtime will not exceed 2 minutes in the vast majority of cases. In case a longer maintenance is required we’ll alert users via in-app messages and announcements on our support forum.