Rezdy API for resellers

Since the API is based on REST principles, it's very easy to write and test applications. You can use your browser to access URLs, and you can use pretty much any HTTP client in any programming language to interact with the API. Features

• REST API
• Supports JSON for requests and responses
• Simple data model
• Secured by SSL and API Key
• Fast and highly available, hosted on Amazon Web Services

If you'd like to build a new service around Rezdy's software, require additional APIs, or would like Rezdy to directly integrate with your company's software, get in touch with our team so we can review your project and discuss its feasibility.

This specification is built upon OpenAPI Specification version 3.0.x.

The examples in the text as well as request and response payloads, use preset data in Rezdy staging environment, and demo accounts with special read-only API Keys. Once you have obtained your API Key from your integrations manager, you can use the account to try any GET calls, however, POST, PUT and DELETE methods are blocked for this API key to preserve the data and will result in the following error

{
    "errorCode": "INVALID_AUTHORIZATION",
    "errorMessage": "Client not authorised"
}

Rezdy API is versioned and you must include the version in the URL you're calling. Our API is actively updated within the same version, but these are non-breaking changes and therefore the version will not be updated. We will increase the version for any major breaking change.

Please check the changelog for details of changes.

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

https://api.rezdy.com/distribution/v2/products

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 include payment processing through 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.

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.

For simple integrations, it is easier to test using the production environment, booking only Test products from our Rezdy Reseller Certification operator.

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

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

We do not allow Cross-Origin Resource Sharing (CORS), REST calls to Rezdy API should not be made directly from a browser.

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:

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

or

GET https://api.rezdy.com/distribution/v2/products

HTTP headers:
apiKey: XXXXXXXXXXXXXXXXXXXX

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 partnerintegrations@rezdy.com

Keep API key confidential and do not publish it to any publicly available repository in a version control system. Malicious bots are frequently scanning for such vulnerabilities.

Media Types

The Rezdy API supports UTF-8 encoded JSON payload. You must include both Accept and Content-Type headers to your requests as follows:

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

Response format

Successful request:

{
  "id": "RCS_67a450caccaccb087b165e76_v4_test_1_en_AU",
  "productCode": "RCS_67a450caccaccb087b165e76_v4_test_1",
  "translation": "en_AU",
  "sourceId": "v4_test_1",
  "sku": "v4_test_1",
  "isMain": true,
  "otherTranslations": [
    "de_AT",
    ...
  ],
  ...
}

Request with error:

{
  "errorCode": "NOT_FOUND",
  "errorMessage": "Product with productCode 'xxxxxxxxxxxx', rezdyLocale 'en_AU' does not exist"
}

Pagination

Requests that return multiple items are paginated to 100 items by default. You can control pagination by using the lastId (default: null) and limit (default: 100) query parameters. The custom limit may not exceed 100, except for specific endpoints if mentioned in their description.

For example:

GET /products?lastId=XXXXXXXXX&limit=100

Dates format

There are 2 date formats in our API model.

The first one is ISO8601 format, and typically fields such as startTime, endTime, dateCreated, dateUpdated are formatted this way.

The other one is a operator's localized date format, which is based on a operator's timezone setup on Rezdy. Typically, used by fields startTimeLocal/endTimeLocal.

How to use them in API requests

These two types are mostly exposed in pairs in the payloads or query parameters as startTime & startTimeLocal or endTime & endTimeLocal. For better convenience, you can choose which format to use. General rules of thumb are:

1. If a start time is required, at least one of the parameters startTime or startTimeLocal have to be specified. Similarly, for other date fields.
2. If both parameters startTime and startTimeLocal are specified in the request, the startTime has a higher priority, startTimeLocal will be simply ignored. Similarly, for other date fields.

Local format

Local format does not contain timezone information, the format is yyyy-MM-dd HH:mm:ss, e.g.:

2015-10-30 09:00:00

Using local date format is recommended, as there is no need to do any timezone conversions when displaying data such as local tour start time to an end user.

ISO8601 format

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

2015-10-29T22:00:00Z

That’s because 2015-10-29T22:00:00Z is the same time as 2015-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 operator’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)

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

Below is a list error codes returned by the API endpoints with respective HTTP Statuses. Any error code marked as retriable could be retried at a later time without the change of the request payload. Non-retriable error codes will require a change of the payload data, operator's setup, or mark a persistent state. Retrying such requests without such external change will still fail.

{
 "errorCode" : "INVALID_ARGUMENT",
 "errorMessage" : "Invalid Start time provided.",
 "invalidFields" : [
    {
      "label" : "startTimeLocal",
      "reason" : "Start time local '2025/01/01T10:00' is invalid, expecting format 'yyyy-MM-ddTHH:mm:ss'."
    }
  ]
}

{
 "errorCode" : "NO_AVAILABILITY",
 "errorMessage" : "No of tickets requested 6 Adults is more than the current quantity available",
 "quantityAvailable" : 2
}

{
 "errorCode" : "INVALID_AUTHENTICATION",
 "errorMessage" : "Missing API key."
}
}

{
 "errorCode" : "INVALID_AUTHORIZATION",
 "errorMessage" : "The channel does not have access to any variation of this product XYZ."
}
}

{
 "errorCode" : "MINIMUM_QUANTITY_REQUIRED",
 "errorMessage" : "Booking of variation XYZ requires at least 3 participants.",
 "quantityRequiredMin" : 3
}

{
 "errorCode" : "MAXIMUM_QUANTITY_REACHED",
 "errorMessage" : "Booking of variation XYZ reached beyond the limit of 10 participants.",
 "quantityRequiredMax" : 10
}

{
 "errorCode" : "INVALID_BOOKING",
 "errorMessage" : "Reservation with id XYZ does not exist."
}

{
 "errorCode" : "INVALID_VARIATION",
 "errorMessage" : "Product variation XYZ does not exist in the system"
}

{
 "errorCode" : "INVALID_GUEST_TYPE",
 "errorMessage" : "Invalid guest types, product variation XYZ does not have provided guest types.",
 "priceOptions" : [
  {
   "label" : "Student"
  },
  {
   "label" : "Senior"
  }
 ]
}

{
 "errorCode" : "HIT_RATE_LIMIT_REACHED",
 "errorMessage" : ""Too Many Requests within a certain time period. Please try again later",
}

{
 "errorCode" : "INTERNAL_ERROR",
 "errorMessage" : "Connection timeout while performing the request"
}

API real-time and historical uptime/availability details are available here.

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.

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:

• Payment processing credit card payments processing is not yet supported in the API
• single booking item per booking Only a single booking item (single product variation) can be booked currently in a booking call, however, multiple guest types and quantities in the item are supported.
• Booking updates Updating booking is not yet supported in the API.
• Return shuttle/Transfer product prices are not exposed through the Rezdy API, but products can be booked independently as 2x one-way products.
• Flexible availability Products with Flexible availability and price per duration or Gift Card style products, cannot be booked through the API

Operator (Tour Operator)

A business supplying products for resale to reseller channels or Rezdy marketplace (B2B) or using Rezdy booking software to sell them to end Guests (B2C).

Reseller (Reseller partner)

A business reselling operator products.

Product (Tour, Activity)

An experience that a operator is selling on Rezdy.

Variation (Tour, Activity)

A variation of the product that an operator is selling on Rezdy.

Booking (Order)

Transaction of selling a variation of the Rezdy operator. Booking and order might be used interchangeably, but refer to the same entity across the specification.

Booking item (Order item)

A booking consist of a single item. An item is linked to a single product, a single or no event product (depending on product booking mode), and can have different quantities and guest types

Reservation

An un-confirmed booking (A booking with status== "RESERVATION_STARTED") that temporarily holds availability.

At the moment reservations are not available in Reseller API.

Timeslot (Tour timeslot)

A timeslot when a product (tour or activity) is scheduled to run at. A timeslot provides information such as start and end time, totalCapacity (seats), quantityAvailable (seatsAvailable) and pricing (guestTypes).

Guest

An entity representing information about an end traveler who booked a product.

Main price

Price that represents the product and all associated variations. This is the one price operator has nominated to display for the product.

Booking form field

A booking questions or information provided during a booking process. Booking form fields can be stored on order level (a booking field per booking) or guest level (a booking field per participant). Booking form fields can be mandatory or optional and may require a certain format.

Upsell (Product extra)

An additional item or service that can be booked together with a product/variation. Extras can have their own availability.

Pickup

A list of pickup locations and additional pickup instructions that are associated with a product, that guest can choose from during booking.

See Providing Guest with pickups for details.

Marketplace

The two-sided B2B platform provided by Rezdy where operators and resellers can search, connect and trade with one another.

Negotiated rate

Negotiated rate allows reseller and operator to agree on a specific commission amount to be used for selected products for their bookings.

Catalog

A complete list of variations, defined by a custom name. Resellers can group variations to a Catalog with naming of their choice to sell.

Category

A pre-defined set of labels to identify the type of product offering. These categories enable consumers to search for product by these labels.

Tag

A custom label that can be assigned to a category to help Resellers group their Catalogs.

Question: Do I still need to send my Reseller booking confirmations to Operators.

Rezdy will notify operators on some bookings depending on their notification configuration. If unsure, please check with your Integrations manager.

Question: Do we need to send a booking confirmation to Guests when we make a reservation.

Rezdy will notify guests on some bookings depending on their notification configuration. If unsure, please check with your Integrations manager.

Question: Is it possible to search the products by address, including country, region, city, etc.

You can only search products by geolocation and radius. Parameters available can be found here. In such case we will return products up to 500 km by default or with specific radius away, ordered by distance from that point. We expect a client system to have some caching or database layer, where you store products you are reselling. You should not make an API query for each end-user request.

You need to follow these steps to use the Reseller API:

1. Sign a Commercial Agreement
   Before accessing the API, prospective resellers must sign a commercial contract with our Reseller Partnerships team. This is a prerequisite for integration.
2. Introduction to Reseller Partner Integrations
   Once the commercial agreement is finalized, resellers will be introduced to our Technical Integrations team. This team will assist in setting up the staging environment and provide support during development.
3. Develop & Integrate
   Using the provided staging environment, resellers can begin building their integration. We recommend reviewing our API Overview, typical use cases, and endpoint specifications. Our team is available to support you throughout this process.
4. Certification
   After development is complete, our Reseller Partner Integrations team will review and certify the API integration to ensure it meets our standards.
5. Production Setup & API Key Generation
   Once certified, we will create the reseller’s Reseller partner account in the production environment and generate their API key. Resellers will then be able to access and use the API to sell products from operators who have shared their rates.
6. Ongoing Support
   Our API Support team remains available for any additional support needed post-integration.

The most typical use case for Reseller partner integration with Rezdy API, is to facilitate Rezdy API data to build a booking site. These examples show the API requests and responses for a typical booking flow. It helps you understand the process to replicate the Rezdy booking form through the API.

That typically consists of the following steps:

1. Load and cache Rezdy product details, available for you to be booked, and refresh it regularly. Get product
2. Load and cache Rezdy product availability, and refresh it regularly. Search availability
3. Build a checkout flow, which includes a real-time availability check of user selected product sessions and booking creation. Create booking
4. Confirm booking with data such as reseller reference, comments or Guest pick location. Confirm booking
5. Cancel a booking Cancel booking

Get product

Reseller can get a product that has been shared by the operator by using the productId, or a variation's Id of the product, or the product's code and translation.

Example Request

GET https://api.rezdy-staging.com/distribution/v2/products/code/RCS_67a450caccaccb087b165e76_v4_test_1/en_AU?apiKey=69f708868ddc45eaa1f9b9fad1ddeba5

Example Response

{
  "id": "RCS_67a450caccaccb087b165e76_v4_test_1_en_AU",
  "productCode": "RCS_67a450caccaccb087b165e76_v4_test_1",
  "translation": "en_AU",
  "sourceId": "v4_test_1",
  "sku": "v4_test_1",
  "isMain": true,
  "otherTranslations": [
    "de_AT",
    "de_DE",
    "tr_TR"
  ],
  "name": "RCv4 Test Product",
  "summary": "This is a v4 test product 1 for Rezdy Connect demonstration and test purpose.",
  ...
}

Search products

Resellers do not own any product. You can use the GET /products endpoint to load products that operator have shared. Product details include general pricing, description, inclusion, exclusion. There are many attributes available on the service, allowing you to filter products by location, operator, category, language of product or language in which variation is offered in, specific inclusions & exclusions etc.

Search availability

Once you have product details, the next step is to retrieve and cache products availability GET /availability endpoint to load availability.

Example Request

GET https://api.rezdy-staging.com/distribution/v2/availability?apiKey=69f708868ddc45eaa1f9b9fad1ddeba5&from=2025-03-02T09:00&to=2025-03-02T09:00&variationIds=RCS_67a450caccaccb087b165e76_v4_test_1_en_AU_v4_test_1_variation_1&variationIds=RCS_67a450caccaccb087b165e76_v4_test_1_de_AT_v4_test_1_variation_2

This loads all the available sessions for product with variation IDs for a period of time in the Operator’s local timezone.

Example Response

{
    "availability": [
        {
            "variationId": "RCS_67a450caccaccb087b165e76_v4_test_1_de_AT_v4_test_1_variation_2",
            "startTime": "2025-03-02T08:00:00Z",
            "startTimeLocal": "2025-03-02T09:00",
            "endTime": "2025-03-02T09:00:00Z",
            "endTimeLocal": "2025-03-02T10:00",
            "quantityAvailable": 100,
            "totalCapacity": 100,
            "allDay": false,
            "guestTypes": [
                {
                    "label": "Adult",
                    "retailPrice": 10000,
                    "sourceId": "adult"
                },
                {
                    "label": "Child",
                    "retailPrice": 5000,
                    "sourceId": "child"
                }
            ]
        }
    ],
    "lastId": "RCS_67a450caccaccb087b165e76_v4_test_1_de_AT_v4_test_1_variation_2-2025-03-02T08:00:00Z-2025-03-02T09:00:00Z"
}

Important information here is:

• startTimeLocal: This is the localized session time you need to send when making a booking for a specific session.
• seatsAvailable: This is the number of seats available for that specific session.
• startTime: It is also possible to use timezone-independent session start time for the product booking. However, only one of the fields startTime or startTimeLocal can be used in the booking request, therefore it is up to you to choose which way is more convenient for your client-side code. See the Dates format section for details.

Create booking

Now when you built and cached products and availability with a price that you are interested in reselling, the next step is a checkout flow.

If the seats are still available, you can create a booking in Rezdy by calling the POST /bookings endpoint.

The following request creates a simple booking for 1 Adult for the product we previously loaded. It’s a $250 booking for 2025-03-02 at 9:00AM in Sydney.

Example Request

POST https://api.rezdy-staging.com/distribution/v2/booking/reserve?apiKey=69f708868ddc45eaa1f9b9fad1ddeba5

{
  "resellerReference" : "ResellerApiDemoBooking1",
  "items": [
    {
      "variationId": "RCS_67a450caccaccb087b165e76_v4_test_1_en_AU_v4_test_1_variation_1",
      "startTimeLocal": "2025-03-02T09:00",
      "guestTypes": [
        {
          "label": "Adult",
          "quantity": 1
        }
      ]
    }
  ],
  "total" : 1000,
  "currency": "AUD"
}

Example Response

{
  "id": "6c08a2ec-de46-4143-aca0-26959260a17f",
  "operatorReference": "operatorReference123",
  "resellerReference": "ResellerApiDemoBooking1",
  "expirationDate": "2025-03-02T23:02:35.830467648Z",
  "status": "RESERVED",
  "items": [
    {
      "variationId": "RCS_67a450caccaccb087b165e76_v4_test_1_en_AU_v4_test_1_variation_1",
      "startTime": "2025-03-01T22:00:00Z",
      "startTimeLocal": "2025-03-02T09:00:00",
      "guestTypes": [
        {
          "label": "Adult",
          "quantity": 1,
          "guestIds": [
            "1"
          ]
        }
      ],
      "itemId": "16f86bd3-72e0-4f6f-8472-72b29738b4ec",
      "pickup": {
        "name": "V4 test pickup location",
        "additionalNotes": "V4 test pickup location additional info",
        "otherPickupLocationAllowed": true,
        "otherLocationInstructions": "V4 test pickup location, other location instructions",
        "pickupLocations": []
      },
      "taxes": []
    }
  ],
  "total": 1000,
  "currency": "AUD"
}

Confirm booking

POST /booking/confirm endpoint allows you to confirm an existing booking.

Example Request

POST: https://api.rezdy-staging.com/distribution/v2/booking/confirm?apiKey=69f708868ddc45eaa1f9b9fad1ddeba5

{
  "id" : "6c08a2ec-de46-4143-aca0-26959260a17f",
  "resellerReference" : "ResellerApiDemoBooking1",
  "items": [
    {
      "itemId": "16f86bd3-72e0-4f6f-8472-72b29738b4ec",
    }
  ]
}

Example Response

{
  "id": "6c08a2ec-de46-4143-aca0-26959260a17f",
  "operatorReference": "operatorReference123",
  "resellerReference": "ResellerApiDemoBooking1",
  "status": "CONFIRMED",
  "items": [
    {
      "itemId": "16f86bd3-72e0-4f6f-8472-72b29738b4ec",
      "productId": "RCS_67a450caccaccb087b165e76_v4_test_1_en_AU",
      "variationId": "RCS_67a450caccaccb087b165e76_v4_test_1_en_AU_v4_test_1_variation_1",
      "startTime": "2025-03-01T22:00:00Z",
      "startTimeLocal": "2025-03-02T09:00:00",
      "guestTypes": [
        {
          "label": "Adult",
          "quantity": 1,
          "price": 1000
        }
      ],
      "operatorReference": "",
      "guests": []
    }
  ],
  "tax": {},
  "total": 1000,
  "currency": "AUD"
}

Cancel booking

To cancel a booking use POST booking/cancel endpoint as in example below with an empty request body.

Example Request

POST https://api.rezdy-staging.com/distribution/v2/booking/cancel?apiKey=69f708868ddc45eaa1f9b9fad1ddeba5

{
  "id" : "6c08a2ec-de46-4143-aca0-26959260a17f",
  "resellerReference" : "ResellerApiDemoBooking2",
  "items": [
    {
      "itemId":  "ecd62bea-f743-4a2f-a34b-64ec3700eda1",
    }
  ]
}

Example Response

{
  "id": "6c08a2ec-de46-4143-aca0-26959260a17f",
  "operatorReference": "operatorReference123",
  "resellerReference": "ResellerApiDemoBooking2",
  "status": "CANCELLED",
  "items": [
    {
      "itemId":  "ecd62bea-f743-4a2f-a34b-64ec3700eda1",
      "operatorReference": "",
    }
  ]
}

Resellers do not own any product. You can use the GET /products endpoint to load products that operator have shared. Product details include general pricing, description, inclusion, exclusion. There are many attributes available on the service, allowing you to filter products by location, operator, category, language of product or language in which variation is offered in, specific inclusions & exclusions etc.

To optimise the performance it is better to call search products and cache the retrieved products for at least 24 hours. Products do not tend to be updated by operator often.

Search filters should be rather implemented on client side to avoid round-trips to Rezdy API for each user query. Search product is a resource intensive query and depending on the search filters used, it can take up to several seconds to get a response.

Example request:

GET https://api.rezdy-staging.com/distribution/v2/products?apiKey=69f708868ddc45eaa1f9b9fad1ddeba5&latitude=48.8&longitude=20.3

Example response:

{
  "products": [
    {
      "id": "RCS_67a450caccaccb087b165e76_v4_test_1_en_AU",
      "productCode": "RCS_67a450caccaccb087b165e76_v4_test_1",
      "translation": "en_AU",
      "sourceId": "v4_test_1",
      "sku": "v4_test_1",
      "isMain": true,
      "otherTranslations": [
        "de_AT",
        "de_DE",
        "tr_TR"
      ],
      "name": "RCv4 Test Product",
      "summary": "This is a v4 test product 1 for Rezdy Connect demonstration and test purpose.",
      "details": "<h1>This is a v4 test product 1 for Rezdy Connect demonstration and test purpose.</h1>. It complies with the RezdyConnect version 4 specification. It contains all mandatory field and some optional, to see a full example please see the RezdyConnect specification.",
      "highlights": [
        "Highlight location 1",
        "Highlight location 2",
        "Highlight location 2"
      ],
      "inclusions": [
        "Inclusion 1",
        "Inclusion 2",
        "Inclusion 2"
      ],
      "exclusions": [
        "Exclusion 1",
        "Exclusion 2",
        "Exclusion 2"
      ],
      "images": [
        {
          "url": "https://rezdy-images-test.s3.us-west-1.amazonaws.com/IMG_5565.jpg",
          "title": "Image 1 title"
        }
      ],
      "isAppointmentNeeded": true,
      "faqParticipants": "Faq1: Answer1, Faq2: Answer2",
      "additionalInformation": "Additional Information",
      "customerShouldBring": "Customer Should Bring",
      "locationAddress": {
        "googlePlaceId": "0",
        "locationName": "V4 test product location",
        "address": "V4 test product location address",
        "locationInfo": "V4 test product location info",
        "latitude": 0.0,
        "longitude": 0.0
      },
      "meetingPoint": {
        "googlePlaceId": "0",
        "locationName": "V4 test meeting point location",
        "address": "V4 test meeting point address",
        "locationInfo": "V4 test meeting point info",
        "latitude": 0.0,
        "longitude": 0.0
      },
      "pointsOfInterest": [
        {
          "googlePlaceId": "0",
          "locationName": "V4 test Point Of Interest location",
          "address": "V4 test Point Of Interest address",
          "locationInfo": "V4 test Point Of Interest info",
          "latitude": 0.0,
          "longitude": 0.0,
          "relationType": "ADMISSION_TICKET"
        }
      ],
      "pickup": {
        "id": "0",
        "name": "V4 test pickup location",
        "validFrom": "2024-10-22T00:00:00",
        "validTo": "2025-10-22T00:00:00",
        "additionalNotes": "V4 test pickup location additional info",
        "otherPickupLocationAllowed": true,
        "otherLocationInstructions": "V4 test pickup location, other location instructions",
        "makeYourOwnWay": true
      },
      "variations": [
        {
          "id": "RCS_67a450caccaccb087b165e76_v4_test_1_en_AU_v4_test_1_variation_1",
          "sourceId": "v4_test_1_variation_1",
          "variationMappingId": "P3Z8FC",
          "name": "V4 test product 1 Variation 1",
          "offerLanguages": [
            "en_US",
            "de_DE",
            "es_ES",
            "de_AT",
            "tr_TR"
          ],
          "guestTypes": [
            {
              "sourceId": "adult",
              "label": "Adult",
              "originalPrice": 12000
            },
            {
              "sourceId": "child",
              "label": "Child",
              "originalPrice": 6000
            }
          ],
          "formFields": [
            {
              "label": "First Name",
              "type": "TEXT",
              "guest": {},
              "displayOther": false,
              "sortOrder": 1
            },
            {
              "label": "Last Name",
              "type": "TEXT",
              "guest": {},
              "displayOther": false,
              "sortOrder": 2
            },
            {
              "label": "E-mail",
              "type": "TEXT",
              "guest": {},
              "displayOther": false,
              "sortOrder": 3
            }
          ]
        }
      ],
      "timezone": "Australia/Sydney",
      "currency": "AUD",
      "operator": {
        "id": "67b6b459d289b8505d62e3e0",
        "alias": "apispecificationdemosupplierdonotedit"
      },
      "barcodeOutputType": "ORDER",
      "isUpsell": false,
      "upsells": [],
      "ratings": {
        "rating": 100,
        "count": 4.5
      },
      "accessibilityTags": [
        "MOBILITY_ACCESSIBLE"
      ],
      "suitabilityTags": [
        "SINGLES",
        "FAMILY"
      ],
      "durationTags": [
        "SHORT_TRIPS"
      ],
      "themeTags": [
        "FOOD_AND_DRINKS"
      ],
      "categoryTags": [
        "FOOD_TOURS"
      ],
      "operatorCatalogs": [
        {
          "value": "Walking tours",
          "sortOrder": 1
        },
        {
          "value": "Walking tours",
          "sortOrder": 1
        }
      ],
      "sortOrder": 1,
      "waitListingEnabled": false,
      "taxes": [],
      "openingHours": [
        {
          "from": "2024-10-22T00:00:00",
          "to": "2025-10-23T00:00:00",
          "daysOfTheWeek": [
            {
              "day": "SATURDAY",
              "times": [
                {
                  "openTime": "08:00:00",
                  "closeTime": "17:00:00"
                }
              ]
            },
            {
              "day": "SUNDAY",
              "times": [
                {
                  "openTime": "08:00:00",
                  "closeTime": "17:00:00"
                }
              ]
            }
          ]
        }
      ]
    }
  ],
  "lastId": "RCS_67a450caccaccb087b165e76_v4_test_1_en_AU"
}

Note: This feature is disabled by default. Please contact Rezdy Support if you want to enable it.

Two steps booking flow is useful for minimising availability errors during a Guest checkout, thereby achieving a better Guest experience.

Typical flow with 2 steps booking process follow these steps:

1. Create a reservation: call Rezdy API /reserve to create a reservation (an order with RESERVATION_STARTED status) upon a Guest cart checkout. This will create an order, which holds reserved product's timeslot availability typically for 60 minutes (may depend on an integrated third party BSw) or until cancelled.
2. Confirm/cancel it: process Guest information or payment in your portal. Once done, call Rezdy to confirm the booking (set status to CONFIRMED). Alternatively, cancel the reservation to free the availability when checkout process was abandoned or failed. If it's not done manually, Rezdy will do so after 60 minutes.

Create a reservation: call Rezdy API to create a reservation (an order with RESERVATION_STARTED status at first) upon a Guest cart checkout. Once the reservation has been successfully processed, a response with status RESERVED will be returned to the Reseller which holds reserved product's session's availability for at least 60 minutes or until cancelled.

POST https://api.rezdy-staging.com/distribution/v2/booking/reserve?apiKey=69f708868ddc45eaa1f9b9fad1ddeba5

{
    "status": "RESERVED", 
    "items": {
    ...	
}

Confirm a reservation - update the booking to CONFIRMED status:

POST https://api.rezdy-staging.com/distribution/v2/booking/confirm?apiKey=69f708868ddc45eaa1f9b9fad1ddeba5

{
    "status": "CONFIRMED", 
    "items": {
    ...	
}

TO BE UPDATED Note: If a product confirmMode is not set as AUTOCONFIRM the resulting order status might not be CONFIRMED. An order can end up with a PENDING_SUPPLIER status. Another case is, if the used payment option requires Guest to process a payment in a third party provider, such as PayPal. In such case the status will be PENDING_CUSTOMER

Alternatively, to free up the reserved availability, update a booking to CANCELLED status, the later option will cause the order to be hidden from UI screens:

POST https://api.rezdy-staging.com/distribution/v2/booking/cancel?apiKey=69f708868ddc45eaa1f9b9fad1ddeba5

{
    "status": "CANCELLED", 
    "items": {
    ...	
}

[TO BE CONFIRMED] If a product is configured isAppointmentNeeded, the booking date and time have to match a session startTime; otherwise there is no need to specify booking date and time in a booking request.

Once a pickup is configured for a certain product, the product detail will contain a field pickupId. The Id value is not required for further use in other API calls (it's for the future purpose), for now on it just means the pickups are configured for this product.

For example:

https://api.rezdy-staging.com/distribution/v2/products/code/RCS_67a450caccaccb087b165e76_v4_test_1/en_AU?apiKey=69f708868ddc45eaa1f9b9fad1ddeba5 

RESPONSE:

{  
  "id": "RCS_67a450caccaccb087b165e76_v4_test_1_en_AU",
  "productCode": "RCS_67a450caccaccb087b165e76_v4_test_1",
  "translation": "en_AU",
  ...  
  "pickup": {
    "id": "0",
    "name": "V4 test pickup location",
    "validFrom": "2024-10-22T00:00:00",
    "validTo": "2025-10-22T00:00:00",
    "additionalNotes": "V4 test pickup location additional info",
    "otherPickupLocationAllowed": true,
    "otherLocationInstructions": "V4 test pickup location, other location instructions",
    "makeYourOwnWay": true
  },
  ...
}

Booking fields define what additional information operators require at booking time. This can include participant-specific details or item-specific options, such as participant names, dietary requirements, or the preferred language of the tour guide. These fields can be required either once per booking item or for each participant.

Booking Fields in Reservation Response

When you create a reservation, the response includes a list of booking fields under each booking item or guest type. These fields indicate what information needs to be collected before confirming the booking.

The following structure shows how each booking field is represented in the reservation response:

{
  "label": "string",
  "required": true,
  "choices": ["Option1", "Option2"]
}

• label: The name of the field (e.g., "First Name", "Last Name").
• required: If true, this field must be included in the confirm booking request.
• choices: If present, the value must be one of the provided options (e.g., "Vegetarian", "Vegan").

These booking fields are found either:

• Under ReservationResponse.items[].fields (item-level fields), or
• Under ReservationResponse.items[].guestTypes[].fields (guest-level fields per type, such as Adult or Child)

Item-level fields apply once per booking item (e.g., tour-specific preferences), whereas guest-level fields apply to each individual guest (e.g., first and last name).

Booking Fields in Confirm Booking Request

In the confirm booking step, you must include all required booking fields returned in the reservation response.

All values are submitted as strings, regardless of their intended type (e.g., boolean, date, number). The expected format is:

{
  "label": "string",
  "value": "string"
}

• label: Must match the one returned in the reservation response.
• value: A string value filled in by the reseller or customer.

Value Formatting Guidelines

Use the following formatting guidelines for the value field:

• Boolean values: "true" or "false"
• Dates: ISO-8601 format, e.g., "2025-08-01"
• DateTimes: ISO-8601 format with time, e.g., "2025-08-01T09:00:00Z"

Mapping GuestType Fields to Guests

In the reservation response, booking fields are provided per GuestType. Below is an example of a GuestType object in the reservation response:

{
  "label": "Adult",
  "quantity": 2,
  "guestIds": ["1", "2"],
  "fields": [
    {
      "label": "First Name",
      "required": true
    },
    {
      "label": "Last Name",
      "required": true
    }
  ]
}

When confirming the booking, these fields must be included for each guest of that type in the request. Below is an example of an Item object in the confirm booking request:

{
  "itemId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "fields": [
    {
      "label": "Language Preference",
      "value": "English"
    }
  ],
  "guests": [
    {
      "guestId": "1",
      "guestType": "Adult",
      "fields": [
        {
          "label": "First Name",
          "value": "Alice"
        },
        {
          "label": "Last Name",
          "value": "Smith"
        }
      ]
    },
    {
      "guestId": "2",
      "guestType": "Adult",
      "fields": [
        {
          "label": "First Name",
          "value": "Bob"
        },
        {
          "label": "Last Name",
          "value": "Brown"
        }
      ]
    }
  ]
}

This structure shows how both item-level and guest-level booking fields are submitted in the confirm booking request. Each guest must include all required booking fields for their guestType, using the same label names from the reservation response.

Summary

Ensure that:

• All required fields from the reservation response are included in the confirm booking request.
• The label values in the confirm request must exactly match the ones returned in the reservation response.
• Value formatting conventions are followed ("true", "false", ISO-8601 strings).

v2 is now available. If you would like to view Changelog for v1, this can be accessed here