API Overview


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 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, 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.
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


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



We have Staging and Production environment. Use Staging environment to test your integration to make sure it is ready before connecting with the Production server. Third party calls in Rezdy Staging environment including 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 will have to create a new account and generate a new API key on our Staging server in order to use it.

Note: We are currently setting up the Staging environment replication. Staging environment data will be regularly replicated from Production, but cleaned from any sensitive data.

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

Environment Application URL API URL API Documentation URL
Staging https://app.rezdy-staging.com https://api.rezdy-staging.com https://developers.rezdy-staging.com
Production https://app.rezdy.com https://api.rezdy.com https://developers.rezdy.com

When testing an Agent integration, it is easier to only use the production environment, and book Test products from our Certification supplier.

On the Staging environment, you can activate a supplier account with credit card number 4242424242424242, to prevent account's expiration.

We usually release new updates to the Staging environment one week before they're applied to production, so there may be differences. Check the changelog for details.


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

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


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

HTTP headers:

To obtain your API Key, please send a request through Integrations > Rezdy API > Request API Key.

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. Using the Local format is recommended.

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.

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


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)


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=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 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"


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 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 business system has no implementation for the intended request.
3 BIZ_RULE Indicates that the XML 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 actively updated, we regularly add new endpoints and features to support more use cases. There are however current limitations:

  • Updating bookings is limited to status, customer & participant details. Updating product or date is not supported.
  • Rental products or custom products with a price per duration, cannot be booked through the API yet ("productType": "RENTAL", or for custom products "productType": "CUSTOM" and all priceOptions.label = "Quantity")
  • Return shuttle/Transfer product prices are not exposed through the 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 using API, however they can be booked via API


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

We use a high availability architecture. Releases should be transparent and backwards-compatible. In case a maintenance period is required we'll alert users via in-app messages and announcements on our support forum.