Rezdy API Overview


The Rezdy API is a REST (REpresentational STate) based API which allows you to read and, in certain cases, write data for resources linked to your Rezdy Booking Software account. The API makes use of 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 listed above. Please check the complete list of available operations in API reference.

Media Types

The Rezdy API supports both XML and JSON formats. You must include both Accept and Content-Type headers to your requests as 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


Rezdy API is versioned and you must include the version in the URL you're calling. Our API is actively updated but these are non-breaking changes and therefore the version will not be updated. Please check the changelog for details of changes.

We are currently on v1 of the Rezdy API. If, for example, you were accessing the Products endpoint, the URl should be structured as:

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


We have Staging and Production environment. Use the Staging environment to test your integration to make sure it is ready before connecting to the Production environment. Calls to the Rezdy Staging environment which include payment processing though payment gateways are done against third-party sandbox environments.

Production and Staging environments are currently completely disconnected, accounts and other data are not replicated, thus you need to create a new account and generate a new API key for each environment.

All requests must use HTTPS, the API is not available on non-SSL/TLS ports.

Environment Application URL API URL API Documentation URL

We release new updates to the Staging environment approximately one week before they are released to production, so there may be differences. These differences will be represented in the documentation available for each environment as outlined above. Check the changelog for details.

If you are an Agent/Reseller and connecting the Rezdy API, it is easier to test using the production environment, booking only Test products from our Certification supplier.

On the Staging environment, you can activate our test supplier account with credit card number 4242424242424242 which will prevent the account from expiring due to the trial ending.


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




HTTP headers:

To obtain your API Key, please log in to your Rezdy Booking Software and send a request by going to the menu item Integrations > Rezdy API > Request API Key. If you do not see this menu item, please contact

Response format

All responses will contain a "requestStatus" element. That element will tell you if your request was successful and may contain error or 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 the supplier's Local time based on their timezone and attributes are called startTimeLocal/endTimeLocal. The second is ISO8601 format and attributes are called startTime/endTime.

Using the Local format is recommended.

Local format

If you use the Local format, you will receive and return:

2014-10-30 09:00:00

You don't need to do any Timezone conversion when using the Local format.

ISO8601 format

If you use ISO8601 format, you must convert timestamps to the supplier’s timezone when you would like 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, timestamp in ISO8601 format returned by the API will be:


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 are both valid and both represent the same timestamp. You can retrieve the supplier's timezone in GET /products calls (a Product.timezone).

Please be mindful of Daylight Savings Time when converting timestamps. Always use the correct timezone (e.g. "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).


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.

For example:

GET /products?offset=0&limit=100
GET /products?offset=100&limit=100
GET /products?offset=200&limit=100

Usage throttling

API use is restricted to 100 calls per minute, per API Key. We may alter this limit based on usage patterns. If you reach your limit, you will receive an HTTP Status 406 response with message "Too Many Requests".


To provide the best experience to your customers and to 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 website Rezdy API Call Caching recommendation
Browse product 1 GET /products/{product1} Cache for 24+ hours
Check product 1 availability GET /availability Cache for 24 hours
Browse product 2 GET /products/{product2} Cache for 24+ hours
Check product 2 availability GET /availability Cache for 24 hours
Add product 2 to shopping cart – Starts checkout GET /availability No Cache – confirms product is still available
Completes checkout POST /bookings No Cache

Error codes

The following error codes can be returned in the requestStatus object

Error code Meaning Details
1 UNKNOWN Indicates an unknown error.
2 NO_IMPLEMENTATION Indicates that the target API has no implementation for the request.
3 BIZ_RULE Indicates that the message has passed a low-level validation check, but that the business rules for the request message were not met.
4 AUTHENTICATION Indicates the message lacks adequate security credentials
5 AUTHENTICATION_TIMEOUT Indicates that the security credentials in the message have expired
6 AUTHORIZATION Indicates the message lacks adequate security credentials
7 PROTOCOL_VIOLATION Indicates that a request was sent within a message exchange that does not align to the message
8 TRANSACTION_MODEL Indicates that the target business system does not support the intended transaction-oriented operation
9 AUTHENTICAL_MODEL Indicates the type of authentication requested is not recognized
10 MISSING_FIELD Indicates 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 in active development with regular new endpoints and features being added to support more use cases. There are, however, some current limitations:

  • Updating bookings is limited to status, customer & participant details. Updating product or date is not supported.
  • Rental products, custom products with a price per duration or GIFT_CARD products, cannot be booked through the API yet (see isApiBookingSupported field in Product response model)
  • Return shuttle/Transfer product prices are not exposed through the Rezdy API, but products can be booked independently as 2x one-way products.
  • Availability limited per price option is not supported. These products can be booked but only the total availability per session is exposed.
  • GIFT_CARD type products cannot be created or booked using the Rezdy API


API real-time and historical uptime/availability details are publicly available. Click here view on our current and historical API status.

We use a highly available architecture and hosting resources with Amazon Web Services. Our standard releases are transparent, therefore causing no downtime, and are backwards-compatible unless it is a major version release (see versioning above). In case a maintenance period is required we will alert users via in-app messages and announcements on our support forum and our Rezdy Ops Twitter account.