API Overview

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

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.

Production and Test environments are 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 Test server in order to use it.

Note: We are currently setting up a new Stage environment. Stage environment data will be regularly replicated from Production, but cleaned from any sensitive data. Also, all the external calls including payment gateways will be done against third party test environments, same as in Test environment. However, at the moment the Stage environment is sharing the same data with test environment

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

Environment Application URL API URL API Documentation URL Uptime
Test https://app.rezdy-test.com https://api.rezdy-test.com https://developers.rezdy-test.com Weekdays 7am to 7pm (AEST)
Stage https://app.rezdy-test.com https://api.rezdy-staging.com https://developers.rezdy-staging.com 24/7
Production https://app.rezdy.com https://api.rezdy.com https://developers.rezdy.com 24/7

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

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

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

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)

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

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

Availability

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.