The RezdyConnect API powers the external supply side of Rezdy’s Channel Manager tool. The API is designed for ticketing systems needing to expand their channel management capabilities, and for suppliers of any size, using any ticketing system, who want access to Rezdy’s extensive distribution network.

The API is hosted by the supplier or ticketing system, with Rezdy acting as the client. Rezdy makes requests to pull availability and pricing, and pushes bookings and cancellations to the supplier system. Supplier endpoints must respond with data according to the RezdyConnect specification.

For Suppliers:

• Access Rezdy Channel Manager’s features and extensive distribution network, while using a booking system other than Rezdy.

• Able to build and maintain the API connection into Rezdy, allowing for full end-to-end automation via suppliers proprietary booking system.

For Ticketing and Booking Systems:

• Provide customers (suppliers) with full end-to-end automation & channel manager features directly through your source system.

• Enable customers (suppliers) to access the largest, most varied distribution network directly through your source ticketing system.

• Able to build and maintain an API connection into Rezdy that meets technical requirements and specifications.

Rezdy offers different API products for different types of businesses. Make sure to choose the right one for your needs.

Rezdy API for agents

REST API for Rezdy agents and OTAs (online travel agents), providing functionality to resell suppliers products, including pulling shared products, availability and pricing from Rezdy, and pushing bookings and cancellations to Rezdy.

Rezdy API for agents specification

Rezdy API for suppliers

REST API for suppliers using Rezdy Booking Software provides functionality to manage their Rezdy inventory and booking capabilities.

Rezdy API for suppliers specification

RezdyConnect (RC)

The RezdyConnect API powers the supply side of the Rezdy Channel Manager tool. The API is designed for suppliers using other ticketing systems, allowing them to import and resell their products through Rezdy’s connected channels. Rezdy pulls availability and pricing, and pushes bookings and cancellations to the supplier’s booking system.

RezdyConnect specification

Rezdy Webhooks

Webhooks allow 3rd party applications to be notified or updated when certain events happen on Rezdy, by sending data to configured URLs.

Webhooks specification

Supported features of RezdyConnect are:

• Two-step booking flow - reservation/confirmation

• Booking cancellations

• Availability pull / real-time availability push

• Product features including:

  • product content and images

  • customer data / per order booking fields - main customer data and order related data

  • participants booking fields - per booking participant data

  • extras - optional services bookable together with products

  • pickups - including geo location, address, pickup instructions

• Barcodes/QR codes per order or per participant, see reservation or booking response for details

Unsupported features are:

• Booking amendments - normally any OTA originated booking amendments are handled as a new booking creation, followed by a booking cancellation

• Coupons (vouchers and promo codes) - RezdyConnect is not synchronising any discount coupons available in the supplier's system

Interested in learning more about RezdyConnect? Please contact us at

cmsales@rezdy.com

to discuss the connectivity options for ticketing systems and suppliers.

Developing your integration to RezdyConnect now? Email us at

partnerintegrations@rezdy.com

with questions and when you are ready to begin certification.

Already live with the RezdyConnect API? Get in touch with Rezdy for support, question, and advice:

api-support@rezdy.com

To ensure the best booking experience for the end consumer, Rezdy requires all RezdyConnect partners to adhere to the baseline functional requirements and Service Level Agreement (SLA) outlined below.

Note: These requirements exist because of the functionality differences and constraints of connected agents and OTAs. Some variations may be acceptable, depending on the system’s base functionality, but non-compliance may limit the supplier’s choice of distribution partners

To ensure the best booking experience for the end consumer, all RezdyConnect partners must adhere to the Service Level Agreement (SLA) outlined below.

Rezdy will monitor the average response time of all partner integrations. Should the average response time not meet the minimum standard set, Rezdy will work with the partner to make sufficient improvements.

If sufficient improvements are not made within a reasonable timeframe, Rezdy may render the partner ineligible for live connectivity integration.

¹ Hard timeout for all endpoints is 25s.

² Idempotent requests based on the order number, Rezdy may retry calls on timeout or failures

³ Availability must be held for reservations for at least 60 minutes.

⁴ Successful bookings should not fail on business validation, including missing availability or invalid product data. Most business validations should be performed on the step prior (reservation request)

Integration requirements may vary depending on the type of partner. Systems using RezdyConnect fall into these two categories:

• Many-to-one - Booking software integrations into RezdyConnect that will facilitate connections between many suppliers and Rezdy Channel Manager.

  • Typically, any booking software integration is considered many-to-one if it will service multiple suppliers, even when the connection is deployed independently for each supplier.

• One-to-one - A single supplier’s custom solution integrated into RezdyConnect for access to Rezdy Channel Manager.

  • If a single supplier connects many sites or uses multiple accounts in Rezdy Channel Manager, it may best be considered as a many-to-one connection.

If technical constraints prevent you from supporting any of the applicable requirements, please reach out to your Rezdy contact to discuss the impacts and options.

Before starting the integration project, contact Rezdy for the prerequisites steps:

• Technical Scoping

• Commercial Agreements

After commercial agreements have been finalized, engage with Rezdy’s Integrations team:

• Project Kickoff Meeting

  • Access to Rezdy’s staging environment is provided after the kickoff meeting

• RezdyConnect Settings Configuration

• Develop to RezdyConnect API

• Certification

• Supplier Piloting

• Go Live

To complete the supplier's integration into Rezdy, refer to the steps outlined below:

Authentication is required for all interactions between the Booking Software partner and Rezdy. Rezdy supports two types of authentication:

1. API Key - Query parameter based authentication

2. OAuth2 - Token based authentication sent under the Authorization header

API Key

Rezdy receives the apiKey during the Activation process. When received, the apiKey will automatically be appended as the apiKey parameter and sent with each of the service endpoints outlined below. Please notify your Rezdy Contact if the Activation Service will not be supported with the integration.

For example if your exposed endpoints are https://api.supplier.com/xxx, we will append apiKey as follows:

• Availability - https://api.supplier.com/availability?apiKey=yourAPIKey

• Reservation - https://api.supplier.com/reservation?apiKey=yourAPIKey

• Booking - https://api.supplier.com/booking?apiKey=yourAPIKey

• Cancellation - https://api.supplier.com/reservation?apiKey=yourAPIKey

• Product - https://api.supplier.com/booking?apiKey=yourAPIKey

OAuth2

Rezdy supports OAuth2 bearer tokens if the Booking Software partner requires a token based authentication system.

If the Booking Software partner chooses to use this method of authentication, apiKey will be omitted in each request to the Booking Software partner.

Rezdy's requests follow the standard OAuth2 client_credentials grant type protocol.

Please refer to https://www.oauth.com/oauth2-servers/access-tokens/client-credentials/ for the full specs.

Before each request, Rezdy will need to authenticate with the Booking Software partner's system in order to obtain a bearer token.

After a token is received, Rezdy will forward it under the Authorization header:

Authorization: Bearer access_token

If the Booking Software partner wishes to use OAuth2 Rezdy will require the following details:

• Client ID - Unique client identifier for Rezdy to use

• Client Secret - Secret that is paired with the Client ID

• Http Method - Http method type Rezdy will use when calling the supplier's token endpoint. Rezdy supports POST and POST_X_WWW_FORM_URLENCODED

• Token Endpoint - Endpoint to provide bearer tokens for Rezdy to send to the Booking Software partner's system

Example token requests

• Using POST (application/json)

https://{the supplier's_token_endpoint}

Content-Type: application/json

{
    "client_id": "123",
    "client_secret": "secret123",
    "grant_type": "client_credentials"
}

• Using POST_X_WWW_FORM_URLENCODED (application/x-www-form-urlencoded)

https://{the supplier's_token_endpoint}

Content-Type: application/x-www-form-urlencoded

    client_id={client_id}
    &client_secret={client_secret}
    &grant_type=client_credentials

Expected Response Structure

{
    "access_token": "token123",
    "token_type": "bearer",
    "expires_in": 3600
}

Rezdy will cache and re-use the same bearer token until the specified 'expires_in' timestamp returned by the Booking Software Partner before attempting to obtain a new bearer token.

The Booking Software partner may configure OAuth2 settings through query parameters in the Activation link. Please see more information on this here. Should the Booking Software Partner decide to switch from apiKey to OAuth2 later on, Please contact API Support.

This activation process is available to all third-party Booking Software partners to seamlessly onboard their suppliers to the Rezdy Marketplace. This service automates the onboarding process from 'click to connect' to full product creation with the required endpoints.

Note: Direct access to this feature by suppliers should be restricted to prevent duplicate accounts.

Integrate RezdyConnect activation link

Rezdy will provide a redirect link that will navigate suppliers to the Rezdy account activation screen. Rezdy will collect the necessary supplier data to create and activate a ChannelManger account on Rezdy. The target endpoint contains both predefined and generic parameters, which should be appended to the link URL to pre-fill data on the Account activation screen or to provide customisation specific for the supplier's integration. Rezdy will provide separate links for each environment.

The link URL pattern:

https://rc-onboarding.rezdy.com/activate?[parameters]

Parameters

Supported parameters which can be appended to URL as query parameters:

• email: [mandatory] a supplier's company e-mail

• companyName: [mandatory] a supplier's company name

• website: a supplier's company website

• phone: a supplier's phone in international format (e.g. +61400000000)

• country: a supplier's business location - 2-letter ISO country code (e.g. au)

• currency: a supplier's products currency - 3 Letter ISO 4217 currency codes supported by Rezdy (e.g. AUD)

• timezone: a supplier's timezone - Area/Location tz database timezone names (e.g. Australia/Sydney)

• partnerSource: Rezdy defined value. We will let you know the value when it is set up and ready to use.

• rc_apiKey: so that we can call the supplier's API, it should be per supplier. If OAuth2 is the preferred method of authentication, then this field can be omitted.

• rc_oAuthClientId: a supplier's Client ID used by Rezdy to authenticate with the supplier's booking software. Only supply this parameter if the booking software uses OAuth2 instead of apiKey

• rc_oAuthClientSecret: a supplier's Client Secret that is coupled with the Client ID used by Rezdy to authenticate with the supplier's booking software. Only supply this parameter if the booking software uses OAuth2 instead of apiKey

• rc_oAuthTokenEndpoint: a supplier's oauth2 endpoint which Rezdy uses to authenticate with the supplier's booking software. Only supply this parameter if the booking software uses OAuth2 instead of apiKey

• rc_oAuthHttpMethod: the http method used to call a supplier's oauth2 endpoint. Support methods are POST, POST_X_WWW_FORM_URLENCODED. Only supply this parameter if the booking software uses OAuth2 instead of apiKey

• generic RezdyConnect parameters

  • Any parameter prefixed as rc_[parameterName] will be stored on Rezdy and used with every RezdyConnect call where it will be appended to the URL as a query parameter.

• custom integration parameters

  • Please let Rezdy know if the supplier needs any additional parameters specific for the supplier's RC integration that would not be a query parameter. This information will be stored in supplier's RC (RezdyConnect) integration settings and used based on the integration implementation. E.g. an HTTP header with a specific value per supplier, username and password for basic Authorization, part of the endpoints URL is different for each supplier. For now we only support apiKey as auth method, please contact us if the supplier needs something different.

Parameter Encryption

Rezdy activation link must be integrated into secured pages that can only be accessed by authorized users. If the supplier requires additional encryption, Rezdy can issue a certificate to encrypt the query parameters from the URL upon request.

Examples

Given the following values at time of activation:

    email: no-reply@rezdy.com
    companyName: ToursAndActivities
    website: dusan.toursandactivities.com
    partnerSource: PARTNERSOURCECODE
    phone: +61484123456
    country: au
    timezone: Australia/Sydney
    currency: AUD
    rc_apiKey: abcd1234

The URL to generate would be:

https://rc-onboarding.rezdy.com/activate?email=no-reply%40rezdy.com&companyName=ToursAndActivities&website=dusan.toursandactivities.com&phone=%2B61484123456%20&country=au&timezone=Australia%2FSydney&currency=AUD&partnerSource=PARTNERSOURCECODE&rc_apiKey=abcd1234

Given the same values as before but with OAuth2 as the preferred method of authentication.

    email: no-reply@rezdy.com
    companyName: ToursAndActivities
    website: dusan.toursandactivities.com
    partnerSource: PARTNERSOURCECODE
    phone: +61484123456
    country: au
    timezone: Australia/Sydney
    currency: AUD
    rc_oAuthClientId: 123
    rc_oAuthClientSecret: 1234
    rc_oAuthTokenEndpoint: https://tokenendpoint.com
    rc_oAuthHttpMethod: POST_X_WWW_FORM_URLENCODED

The URL to generate would be:

https://rc-onboarding.rezdy.com/activate?email=no-reply%40rezdy.com&companyName=ToursAndActivities&website=dusan.toursandactivities.com&phone=%2B61484123456%20&country=au&timezone=Australia%2FSydney&currency=AUD&partnerSource=PARTNERSOURCECODE&rc_clientId=123&rc_clientSecret=1234&rc_tokenEndpoint=https://tokenendpoint.com&rc_oAuthHttpMethod=POST_X_WWW_FORM_URLENCODED

When the supplier’s account on Rezdy is created, the general settings of the RezdyConnect integration are configured. This configuration is completed by the Rezdy team and may be customized based on the needs of the individual supplier.

General settings

Availability batch refresh settings

Booking flow settings

Oauth2 settings

If OAuth 2 is used as RezdyConnect authentication method with the supplier's system, used the settings below to configure it. Leave blank if API key is used.

Assuming that the supplier's supplier account is ready, there are multiple ways to import products on Rezdy:

• Automated import - (recommended) implement product list endpoint and use product import screen

  • Synchronise products endpoint

  • Use Product Import screen - https://rc-onboarding.rezdy.com/product-import?companyId=[the supplier's_rezdy_company_id]

• Manual method - create products manually using the Rezdy UI

Automated import (recommended)

For automated product import using Rezdy import screen, product endpoint needs to be implemented. The endpoint allows Rezdy to query available products in the supplier's system. See the product list endpoint specification for the required payload and product features which are currently supported.

To import the products, log into the supplier's Rezdy company account and navigate to product import screen. The screen can be accessed from main menu: Inventory -> Products -> Import Products button

Rezdy will list the products from the product import endpoint. It will identify the products already imported (the first on the screenshot with an existing Product Code PTEMMD) and new products not imported yet (a blank Product Code).

Choose the products for import, enter the email address at the bottom of the form and submit it. The import process is asynchronous and it will run in the background, an email will be sent with the results of the import once complete.

Manual products setup

Choose the availability mode, related settings, the booking strategy, and the supported format. Based on the setting, suppliers need to specify necessary endpoints URLs. After the supplier saves the product, Rezdy will request one month availability to ensure the availability endpoint is working. Rezdy will validate URLs for all other endpoints. The supplier will use Rezdy UI to do the configuration.

Using Rezdy UI

Note: For suppliers using a booking software integration, if the Booking Software Partner is on OAuth2 authentication, the supplier can omit the apiKey query parameter in each of the above endpoints.

Scheduling modes (tickets date/times)

Below are the supported product scheduling modes and their impact on RezdyConnect behaviour. Scheduling modes affect how a product is scheduled and whether there is any capacity restriction or date requirement in the booking process.

While all product scheduling modes are supported in the RezdyConnect API, not all scheduling modes may be supported by OTAs. Please consult with Rezdy’s Technical Integrations team to review best practices.

• No Date - a product is available everyday and with no availability limitation; the customer is not required to choose a time when making a booking (some OTAs may require date selection in their UI). Typical examples of No Date products are free-sell tickets, vouchers, gift cards, merchandise.

  • the product will not be part of the availability synchronization batch

  • the available capacity will not be checked before a booking

  • product startTime maybe passed in a booking request, only if the agent/OTA collects it as part of their transaction

  • set bookingMode as NO_DATE in GET /products endpoint, to use this mode

• Any Date - a product is available everyday and there is no availability limitation for these products, but customers will have to choose a time when making a booking. Typically examples of Any Date products are parks, walking tours, wellness appointments.

  • the product will not be part of the availability synchronization batch

  • the available capacity will not be checked before a booking

  • product startTime will be passed in a booking request

  • set bookingMode as DATE_ENQUIRY in GET /products endpoint, to use this mode

• Inventory Free-sell - availability is determined by sessions, but there is no limit for these sessions. Sessions are synchronized using the availability endpoint calls in a synchronization batch. Unlike to Any Date products, the schedule and closeouts of certain days can be managed.

  • the product will be part of the availability synchronization batch

  • the available capacity will not be checked before a booking

  • product startTime will be passed in a booking request

  • set bookingMode as INVENTORY in GET products endpoint and set seats and seatsAvailable as 999 in GET availability endpoint, to use this mode

• Inventory Session based - availability is determined by sessions, they are synchronized using the availability endpoint calls, both batch and before checkout refresh. This mode is typically used for the majority of tours and activities, with managed inventory and limited availability.

  • the product will be part of the availability synchronization batch

  • the available capacity will be checked before a booking

  • product startTime will be passed in a booking request

  • set bookingMode as INVENTORY in GET /products endpoint, to use this mode

RezdyConnect booking process

Rezdy uses a two-step booking process. In this process, a reservation is created in a first call and then confirmed in a second call. This improves the customer experience and maximizes successful bookings by reducing the risk that a booking fails after payment is processed. The two-step booking process minimizes the need for manual intervention by the supplier to handle situations of a failed booking that has been originated by an OTA.

In a booking process Rezdy will use the availability endpoint to refresh availability and pricing. Once the reseller submits a booking to Rezdy, Rezdy will ensure the availability in the supplier's system. Rezdy will then send a booking in 'PROCESSING' state to the supplier's system by calling the Reservation endpoint. If that call fails, we stop the booking process. Otherwise, we create booking internally. If the supplier is using automated payments and the charge fails, the order is cancelled and the supplier's Cancellation endpoint is called. If no error occurs during the booking flow, we call the Confirmation endpoint.

Requests flow for two-steps booking process:

1. Rezdy returns cached sessions to the agent/OTA

2. The agent/OTA indicates the session selected by the consumer

3. Rezdy calls the product's Availability endpoint to refresh the session availability and pricing

4. If there are seats available, agent/OTA can proceed with the booking

5. Booking is created on Rezdy

6. Rezdy calls the product's Booking Reservation Endpoint

7. If an error response is received, Rezdy will refresh the availability for the travel date rejected by the supplier and the booking will be deleted. The reseller will in turn be notified. These default values can be overridden per company, please let Rezdy know if it is required.

8. The customer's payment is processed

9. If any error occurs, the booking will be deleted and Booking Cancellation Endpoint will be called

10. Otherwise Rezdy calls Booking Confirmation Endpoint

Note: Availability refresh call in the flow will be skipped for all scheduling modes except Inventory session based.

Diagram below shows the calls flow for booking originated in OTA systems connected to Rezdy via their APIs

The next step is to implement Rezdy connect endpoints, please refer to the general RC specification for details. We highly recommend implementing two-steps-booking-strategy.

To provide automated products import implement Product endpoint.

Enabling bookings by implementing the following endpoints:

• Availability

• Reservation

• Booking

• Cancellation

To ensure successful bookings and accurate availability for agents and OTAs, Rezdy also recommends implementing push updates of product content and availability:

• Product updates

• Availability updates

Note: Rezdy can use a customized configuration for batch availability refresh, which can be structured to better reflect the supplier's system. The batch start time, frequency, and date range can be configured. Please let Rezdy know if the supplier needs to change the default configuration.

Product code mapping

Rezdy product codes are used when making an availability or booking call, so the supplier can either:

• Use product.internalProduct code field for the supplier's product code (Recommended) – RezdyConnect will populate this as externalProductCode in all RezdyConnect calls (either as a query parameter for availability calls or in the request body for booking requests). If the supplier supports synchronise products endpoint, include products[N].internalCode field in the supplier's response. The field is supported via Rezdy API, too, if the supplier chose to create products that way, or alternatively, the supplier can set it up in UI (product Details tab -> Unique code).

• Product code mapping – Map Rezdy product codes to the supplier's own internal codes and maintain the mapping on the supplier's end in the supplier's RezdyConnect implementation.

Events triggering availability endpoint calls

Several events can result in a call to the external endpoints. Calls to the booking endpoints are based on the booking strategy implemented by the supplier and the product scheduling mode. Availability calls to refresh availability and pricing will occur when:

1. Daily batch update - load the next 6+ months of availability for each product in monthly intervals.

2. The agent/OTA’s customer selects a specific session and starts a checkout process - refresh of the specific session, start and end time are the same (does not apply for the requests with intervals, when multiple sessions are matched).

3. Product scheduling settings are updated - one week of availability is pulled to test the endpoint There is an algorithm that determines if a session should be served from cache or if a refresh is required. It applies when a specific session is requested; therefore, the remote call might not be triggered, but the cached availability is used.

The following rules force the availability refresh from the external endpoint:

• the requested session startTime in less than 7 days ahead,

• the requested session has less than 4 seats available

• the last update of the requested session was more than 10 mins ago

Daily batch update availability calls

Below is an example of the start and end time parameters for batch availability refresh for 6 months. Rezdy will make separate calls for each month, start time is 00:00 of the first day of the month, end time is 23:59:59 last day of the month of the supplier's timezone setup on Rezdy. The exception is the first month, when the start time is set to the current time. Past sessions are never refreshed. In the example, the batch starts on Mar 13 14:20:00 UTC, when the supplier's timezone is UTC+14.

from - to: 2029-05-13T14:20:00.000Z - 2029-05-31T12:59:59.000Z

from - to: 2029-05-31T13:00:00.000Z - 2029-06-30T13:59:59.000Z

from - to: 2029-06-30T14:00:00.000Z - 2029-07-31T13:59:59.000Z

from - to: 2029-07-31T14:00:00.000Z - 2029-08-31T13:59:59.000Z

from - to: 2029-08-31T14:00:00.000Z - 2029-09-30T13:59:59.000Z

from - to: 2029-09-30T14:00:00.000Z - 2029-10-31T13:59:59.000Z

Note: Rezdy can use a customized configuration for batch availability refresh, which can be set up to better reflect the supplier's system. The batch start time, frequency, and date range can be configured. Please let us know if the supplier needs to change the default configuration.

Response

A successful response from the supplier's endpoint must be HTTP status 2xx, and in most cases, it must contain a response entity, see each of the endpoints for details. An error response should use HTTP status 4xx in case of a business error and 5xx in case of an internal error. The response should contain a body with an error code and an error message to provide error details.

Note: A response with status code 2xx, but with an error object, or without the required response entity will be considered as an error response too.

Error response example:

{
  "requestStatus":{
    "error": {
      "errorCode":  "RC_INVALID_DATA",
      "errorMessage": "Failed to create a booking, missing Reseller e-mail.",
      "fields": "Reseller e-mail"
    }
  }
}

Please respond with one of the following HTTP Status and RC Error codes in case of any RezdyConnect call failures. Any call response with an error code marked as retriable may be retried by Rezdy. The errorMessage should be a user friendly text as it will be shown to a customer.

"requestStatus": {
  "error": {
   "errorCode" : "RC_INVALID_DATA",
   "errorMessage" : "Invalid data provided",
   "fields" : [
    {
        "label" : "Email",
        "reason" : "Invalid Reseller Email"
    }
    ]
  }
}

"requestStatus": {
  "error": {
   "errorCode" : "RC_NO_AVAILABILITY",
   "errorMessage" : "No of tickets requested is more than the available seats present",
   "seatsAvailable" : 10
  }
}

"requestStatus": {
  "error": {
   "errorCode" : "RC_AUTH_ERROR",
   "errorMessage" : "Missing Authentication headers"
  }
}

"requestStatus": {
  "error": {
   "errorCode" : "RC_ENDPOINT_UNAVAILABLE",
   "errorMessage" : "Booking Endpoint can not process the request at the moment"
  }
}

"requestStatus": {
  "error": {
   "errorCode" : "RC_MINIMUM_QUANTITY_REQUIRED",
   "errorMessage" : "Booking of product XYZ requires at least 3 participants.",
   "quantityRequiredMin" : 3
  }
}

"requestStatus": {
  "error": {
   "errorCode" : "RC_MAXIMUM_QUANTITY_REACHED",
   "errorMessage" : "Booking of product XYZ reached beyond the limit of 10 participants.",
   "quantityRequiredMax" : 10
  }
}

"requestStatus": {
  "error": {
   "errorCode" : "RC_INVALID_ORDER",
   "errorMessage" : "Order with reservation reference XYZ does not exist"
  }
}

"requestStatus": {
  "error": {
   "errorCode" : "RC_INVALID_PRODUCT",
   "errorMessage" : "Product XYZ does not exist in the system"
  }
}

"requestStatus": {
  "error": {
   "errorCode" : "RC_INVALID_PRICE_OPTION",
   "errorMessage" : "Invalid price options, product XYZ does not have provided price options.",
   "priceOptions" : [
    {
        "label" : "Student"
    },
    {
        "label" : "Group 1-10",
        "min" : 1,
        "max" : 10
    }
    ]
  }
}

"requestStatus": {
  "error": {
   "errorCode" : "RC_MAX_RATE_LIMIT_REACHED",
   "errorMessage" : "Too many requests sent in a particular interval of time.",
   "limit" : 100
  }
}

"requestStatus": {
  "error": {
   "errorCode" : "RC_INTERNAL_ERROR",
   "errorMessage" : "Connection timeout while performing the request"
    }
}

RezdyConnect pulls availability and product content on a regular basis using a scheduled batch, however, for a better user experience, we recommend implementing real-time push updates to trigger an event whenever availability or product changes on the supplier's end. See Product update notification and Availability update notification for details.

2023-11-07

• Product import supports importing booking URL. It is documented under the product endpoint, see a bookingUrl field.

2023-02-01

• Added new RezdyConnect codes along with more detailed description of each by providing examples.

2021-11-11

• Product import supports importing taxes and fees. The taxes and fees model is documented under the product endpoint, see a taxes field.

2021-09-27

• Added more detailed description of productType, bookingMode, confirmMode, extraPriceType fields.

2021-09-27

• Removed OCTo related sections from this specification

2020-11-18

• Added support for order level barcodes.

2020-09-24

• Added support for different barcode output types.

2020-08-31

• Added a guide for automated onboarding of partners supporting OCTo specification

2020-08-24

• Added support for different barcode types.

2019-12-25

• Updated Configure RezdyConnect section

• Updated Automated product import section

2019-12-13

• Added support for OAuth2 authentication

• Added a section for automated account activation, which is used by Booking software partner integrations

2019-06-28

• URL change for RC real-time updates, new domain is https://connect.rezdy[-environment].com/latest/ instead of https://rezdyconnect.rezdy[-environment].com/latest/

2019-06-20

• Specification of SLA timeouts for RezdyConnect endpoints

• Error codes list specification