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

APIs are designed for programmers, so if you don't speak any computer language, we have solutions that should be easier for you to use. Rezdy provides a range of plugins for you to integrate on your website, that don't involve using our API directly. To learn more, check the integration plugins available in your Rezdy account, or read this overview of our iframe plugins

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.

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

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:

• a supplier account API specification demo supplier with API key 5f4b36ff169047a4a5682cba7e07fea4
• an agent account API specification demo agent with API key 69f708868ddc45eaa1f9b9fad1ddeba5

You can use the accounts 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

{
    "requestStatus": {
        "success": false,
        "error": {
            "errorCode": "6",
            "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 v1 of the Rezdy API. If, for example, you were accessing the Products endpoint, the URl should be structured as:

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

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

https://api.rezdy.com/latest/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.

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

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 Agent 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 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/v1/products?apiKey=XXXXXXXXXXXXXXXXXXXX

or

GET https://api.rezdy.com/v1/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 support@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

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

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, except for specific endpoints if mentioned in their description.

For example:

GET /products?offset=0&limit=100
GET /products?offset=100&limit=100
GET /products?offset=200&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 supplier's localized date format, which is based on a supplier'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.:

2014-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 supplier’s timezone when you want to display dates and times for a tour. 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 as 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)

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

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 that credentials are invalid
5 AUTHENTICATION_TIMEOUT	Indicates that the security credentials in the message have expired
6 AUTHORIZATION	Indicates that credentials are valid but not enough permissions to execute that call
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
11 AUTOMATED_PAYMENTS_PRICE_ TOO_LOW_TO_COVER_FEES	Indicate that automated payment booking failed
12 AUTOMATED_PAYMENTS_PRICE_ TOO_LOW_FOR_AGENT_COMMISSION	Indicate that automated payment booking failed
13 PAYMENT_CARD_TYPE_DECLINED	Indicate that the card type is invalid
14 PAYMENT_CARD_TYPE_REJECTED	Indicate that the card type is invalid
15 PAYMENT_ERROR	Indicate that payment information is invalid
16 SINGLE_ORDER_LINE_ITEM_ ALLOWED	Indicate that only a single item per order can be booked for this supplier
17 PAYMENT_REQUIRED_SCA_ ACTION	Indicates that the payment should be completed performing strong customer authentication (SCA)
18 MINIMUM_QUANTITY_REQUIRED	Indicate that quantities are less than the minimal requirement
19 MAXIMUM_QUANTITY_REACHED	Indicate that quantities are higher than the maximum requirement
20 DOWNSTREAM_ERROR	Indicate downstream error
21 NOT_ENOUGH_SEATS_AVAILABLE	Indicate that there are not enough seats available for this session
22 SESSION_NOT_FOUND	indicate that session doesn't find in our system
23 PRODUCT_NOT_FOUND	Indicate that product doesn't find in our system
24 ORDER_NOT_FOUND	Indicate that order doesn't find in our system
25 ORDER_LINE_ITEM_NOT_FOUND	Indicate that order line item doesn't find in our system
26 MIN_BOOK_AHEAD_START_TIME	Indicate that the date of booking must be booked {n} duration before tour start
27 MIN_BOOK_AHEAD_END_TIME	Indicate that the date of booking must be booked {n} duration before tour end
28 INVALID_CUSTOMER_EMAIL	Indicate that the customer email address is not in a valid format
29 BLOCKED_EMAIL	Indicate that the customer email address has been blocked
30 DOWNSTREAM_TIMEOUT	Indicate that the source of the error is a timeout in communication with downstream services. You could retry this call later.
31 INTERNAL_ERROR	Indicate that Rezdy failed to process a request because of an internal error
32 INVALID_PRICE_OPTION	Indicate that the price option used for a booking does not exist on the product
33 REZDYCONNECT_EXTERNAL_SYSTEM	Indicate that external RezdyConnect system did not return mandatory data to finish operation.
34 OTHER_OPERATION_IN_PROGRESS	Indicate that currently there is a session update process running for received product code. You can retry this call shortly.

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:

• 3D-Secure authentication for payments processing is not yet supported in API, therefore Stripe payments (StripeConnect, RezdyPay, Marketplace, and Automated payments) to book EU suppliers' products may not work.
• Updating bookings is limited to status, customer & participant details. Updating products or dates 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
• We don't recommend doing immediate consecutive product updates, session creates, or session updates for the same product code, or a product code of a shared product. This is due to the async session operation that is being triggered and limited to being scheduled once per product (shared products group) at a time.

Supplier (Tour Operator)

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

A supplier can also act as an agent and resell other suppliers' products. In that case, refer to Rezdy API specification for Agents

Agent (Reseller)

A business reselling supplier products.

Product (Tour, Activity)

An experience that a supplier is selling on Rezdy.

Booking (Order)

Transaction of selling a product or multiple products belonging to the same Rezdy supplier. 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 or multiple items. Each item is linked to a single product, a single or no session (depending on product booking mode), and can have different quantities and tour participants.

Reservation

An un-confirmed booking (A booking with orderStatus == PROCESSING) that temporarily holds availability.

At the moment reservations are not available in agent API.

Session (Tour session)

A time slot when a product (tour or activity) is scheduled to run at. A session provides information such as start and end time, total capacity (seats), remaining capacity (seatsAvailable) and pricing (priceOptions).

Customer

An entity representing information about an end customer who booked a product. A booking can have multiple items and each can have a list of participants based on the booked quantities, but only a single main customer per booking.

Participant

An entity representing information about additional tour participants. A booking item is associated with a list of participants.

The first participant always represents the main customer. For your convenience Rezdy automatically copies information from customer entity into the booking first participant in booking requests

Extra (Product extra)

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

Booking field

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

See Using Booking Fields for details.

Pickup

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

See Providing customer with pickups for details.

Resource

An entity such as tour guide, car, boat, etc. that can be associated with sessions. A resource limits session availability and can be shared across multiple sessions.

Coupon (Voucher, Promocode)

A discount that suppliers can offer for customers to apply for their product bookings.

At the moment coupons are not available in agent API.

Manual payment

A booking payment that requires manual reconciliation between agent and supplier outside of Rezdy.

See Bookig workflow for details.

Automated payment

A full booking payment that is required at the time of booking, and is automatically split and paid to supplier and agent.

See Bookig workflow for details.

Marketplace

The two-sided B2B platform provided by Rezdy where suppliers and resellers can search, connect and trade with one another. Only marketplace rate products are available on Rezdy marketplace and only automated payments can be used for marketplace bookings.

Marketplace rate

Marketplace rate allows suppliers to select products available for Rezdy marketplace and set up their commission amount.

Negotiated rate

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

Category

Product categorisation, which allows agents or suppliers to assign Rezdy products to logical groups.

Manifest

A functionality around tour participant manifest, such as check-in, no show flags.

You need to follow these steps to be able to use the Supplier API:

1. Create a supplier account on https://app.rezdy.com, or on https://app.rezdy-staging.com for testing purpose.
2. Create a product. The product should be set up with "Fixed Dates and time" scheduling mode.
3. Create sessions in your calendar. Sessions open availability for your product
4. To obtain your API Key, please send a request through Integrations > Rezdy API > Request API Key.
5. Read our API Overview, check out the typical use cases, examples, and endpoints specification below. Build your client and feel free to get in touch if you have any questions or if you’d like to discuss the implementation of our API services.

You have to request to obtain an initial API Key from our support team. Requests to generate an API key may take up to "48" hours to process. Once generated, the key will automatically appear on the Rezdy API page on the Integrations menu for immediate use. You can request your API key by logging into Rezdy and clicking:

1. Integrations
2. Rezdy API

A typical use case for supplier integration with Rezdy API, is to facilitate Rezdy API data to build a booking site for your Rezdy products. 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 your Rezdy product details, and refresh it regularly. Search 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. Update booking with additional data such participant data, comments or customer pick location. Update booking
5. Cancel a booking Cancel booking

Note: You can also act as an agent and book products of other suppliers, however the payloads are slightly different, therefore in such case follow Rezdy API for agents specification.

Load product details

Agents do not own any product. You must use the GET /products endpoint to load products that suppliers have shared. Product details include general pricing, description and photos. There are many attributes available on the service, allowing you to filter products by location, supplier, category, rate type, etc.

When a customer browses to a specific product page on your website, you should show the product details including general pricing, description and photos using GET /products call.

To optimise the performance it is better to call search products and cache the retrieved products for at least 24 hours, depending on how often you tend to update your products content. Any search filters functionality should be implemented client side.

Example request:

GET https://api.rezdy-staging.com/v1/products?apiKey=5f4b36ff169047a4a5682cba7e07fea4

Example response:

{
    "requestStatus": {
        "success": true,
        "version": "v1"
    },
    "products": [
        {
            "productType": "ACTIVITY",
            "name": "Double dive with sharks",
            "shortDescription": "Double dive with grey nurse or leopard sharks, depending on the season.",
            "description": "Double dive with grey nurse or leopard sharks, depending on the season. Boat dive with a snack provided during the break between the dives. The dive site is suitable for open water divers.",
            "productCode": "PWQF1Y",
            "internalCode": "DIVING",
            "supplierId": 13398,
            "supplierAlias": "apispecificationdemosupplierdonotedit",
            "supplierName": "API specification demo supplier (DO NOT EDIT)",
            "timezone": "Australia/Sydney",
            "advertisedPrice": 200.0,
            "priceOptions": [
                {
                    "price": 250.0,
                    "label": "Adult",
                    "id": 929159,
                    "seatsUsed": 1,
                    "productCode": "PWQF1Y"
                },
                {
                    "price": 200.0,
                    "label": "Student",
                    "id": 929160,
                    "seatsUsed": 1,
                    "productCode": "PWQF1Y"
                }
            ],
            "currency": "AUD",
            "unitLabel": "Participant",
            "unitLabelPlural": "Participants",
            "quantityRequired": true,
            "quantityRequiredMin": 1,
            "quantityRequiredMax": 50,
            "images": [
                {
                    "id": 22650,
                    "itemUrl": "https://img.rezdy-staging.com/PRODUCT_IMAGE/13398/DSCN8351.jpg",
                    "thumbnailUrl": "https://img.rezdy-staging.com/PRODUCT_IMAGE/13398/DSCN8351_tb.jpg",
                    "mediumSizeUrl": "https://img.rezdy-staging.com/PRODUCT_IMAGE/13398/DSCN8351_med.jpg",
                    "largeSizeUrl": "https://img.rezdy-staging.com/PRODUCT_IMAGE/13398/DSCN8351_lg.jpg"
                },
                {
                    "id": 22651,
                    "itemUrl": "https://img.rezdy-staging.com/PRODUCT_IMAGE/13398/DSCN8378.jpg",
                    "thumbnailUrl": "https://img.rezdy-staging.com/PRODUCT_IMAGE/13398/DSCN8378_tb.jpg",
                    "mediumSizeUrl": "https://img.rezdy-staging.com/PRODUCT_IMAGE/13398/DSCN8378_med.jpg",
                    "largeSizeUrl": "https://img.rezdy-staging.com/PRODUCT_IMAGE/13398/DSCN8378_lg.jpg"
                },
                {
                    "id": 22652,
                    "itemUrl": "https://img.rezdy-staging.com/PRODUCT_IMAGE/13398/DSCN1387.jpg",
                    "thumbnailUrl": "https://img.rezdy-staging.com/PRODUCT_IMAGE/13398/DSCN1387_tb.jpg",
                    "mediumSizeUrl": "https://img.rezdy-staging.com/PRODUCT_IMAGE/13398/DSCN1387_med.jpg",
                    "largeSizeUrl": "https://img.rezdy-staging.com/PRODUCT_IMAGE/13398/DSCN1387_lg.jpg"
                },
                {
                    "id": 22653,
                    "itemUrl": "https://img.rezdy-staging.com/PRODUCT_IMAGE/13398/DSCN1402.jpg",
                    "thumbnailUrl": "https://img.rezdy-staging.com/PRODUCT_IMAGE/13398/DSCN1402_tb.jpg",
                    "mediumSizeUrl": "https://img.rezdy-staging.com/PRODUCT_IMAGE/13398/DSCN1402_med.jpg",
                    "largeSizeUrl": "https://img.rezdy-staging.com/PRODUCT_IMAGE/13398/DSCN1402_lg.jpg"
                }
            ],
            "bookingMode": "INVENTORY",
            "charter": false,
            "terms": "",
            "extras": [
                {
                    "name": "Underwater camera rental",
                    "description": "An underwater camera rental for the dive. Choice of GoPro or Nikon Coolpix AW130. Select the number of cameras up to the number of participants, that you would like to rent for this booking.",
                    "price": 15.0,
                    "extraPriceType": "ANY"
                }
            ],
            "bookingFields": [
                {
                    "label": "First Name",
                    "requiredPerParticipant": false,
                    "requiredPerBooking": true,
                    "visiblePerParticipant": true,
                    "visiblePerBooking": true,
                    "fieldType": "String"
                },
                {
                    "label": "Last Name",
                    "requiredPerParticipant": false,
                    "requiredPerBooking": true,
                    "visiblePerParticipant": true,
                    "visiblePerBooking": true,
                    "fieldType": "String"
                },
                {
                    "label": "Mobile",
                    "requiredPerParticipant": false,
                    "requiredPerBooking": true,
                    "visiblePerParticipant": false,
                    "visiblePerBooking": true,
                    "fieldType": "Phone"
                },
                {
                    "label": "Email",
                    "requiredPerParticipant": false,
                    "requiredPerBooking": true,
                    "visiblePerParticipant": false,
                    "visiblePerBooking": true,
                    "fieldType": "String"
                },
                {
                    "label": "Special Requirements",
                    "requiredPerParticipant": false,
                    "requiredPerBooking": false,
                    "visiblePerParticipant": false,
                    "visiblePerBooking": true,
                    "fieldType": "String"
                },
                {
                    "label": "Certification level",
                    "requiredPerParticipant": false,
                    "requiredPerBooking": false,
                    "visiblePerParticipant": true,
                    "visiblePerBooking": false,
                    "fieldType": "String"
                },
                {
                    "label": "Certification number",
                    "requiredPerParticipant": false,
                    "requiredPerBooking": false,
                    "visiblePerParticipant": true,
                    "visiblePerBooking": false,
                    "fieldType": "String"
                },
                {
                    "label": "Certification agency",
                    "requiredPerParticipant": false,
                    "requiredPerBooking": false,
                    "visiblePerParticipant": true,
                    "visiblePerBooking": false,
                    "listOptions": "PADI\r\nSSI\r\nSDI",
                    "fieldType": "List"
                }
            ],
            "latitude": -28.6113488,
            "longitude": 153.629085,
            "confirmMode": "AUTOCONFIRM",
            "confirmModeMinParticipants": 0,
            "commissionIncludesExtras": false,
            "cancellationPolicyDays": 7,
            "dateCreated": "2021-08-30T23:49:55Z",
            "minimumNoticeMinutes": 1440,
            "durationMinutes": 180,
            "dateUpdated": "2021-09-13T04:13:35Z",
            "pickupId": 475,
            "locationAddress": {
                "addressLine": "Julien rocks",
                "postCode": "",
                "city": "Byron Bay",
                "state": "",
                "countryCode": "au",
                "latitude": -28.6113488,
                "longitude": 153.629085
            },
            "languages": [
                "en_au"
            ],
            "tags": [
                "TYPE:Activity"
            ],
            "waitListingEnabled": false,
            "isApiBookingSupported": true
        }
    ]
}

The response includes a few important attributes that you will need to make a booking:

• Price options: You can see there are 2 price options, with different labels (Adult, Student). When you make a booking you should send the exact same label in the Quantity.optionLabel attribute. You do not need to store or send priceOption Ids.
• Booking Fields: This is a list of the various fields suppliers require when making a booking. Some fields can be required once per booking and should be added to the Booking.fields[] array. Others can be required once per participant and should be added to the BookingItem[].participants[].fields[] array for each participant.

Check availability

When a customer wants to check availability for a specific product, you can call the GET /availability endpoint to load availability.

Example Request

GET https://api.rezdy-staging.com/v1/availability?apiKey=5f4b36ff169047a4a5682cba7e07fea4&productCode=PWQF1Y&startTimeLocal=2025-10-01 00:00:00&endTimeLocal=2025-10-03 00:00:00

This loads all the available sessions for product with code PF6B25 for the whole month of November 2014 in the supplier’s local timezone.

It is possible to load availability for multiple products in a single request. Simply add multiple productCode attributes to the request:

GET https://api.rezdy-staging.com/v1/availability?apiKey=5f4b36ff169047a4a5682cba7e07fea4&productCode=P00TNX&productCode=PWQF1Y&startTimeLocal=2025-10-01 00:00:00&endTimeLocal=2025-10-03 00:00:00

We recommend using startTimeLocal and endTimeLocal attributes, instead of startTime and endTime. These older attributes required you to send the timezone as part of your request.

GET https://api.rezdy-staging.com/v1/availability?apiKey=5f4b36ff169047a4a5682cba7e07fea4&productCode=P00TNX&productCode=PWQF1Y&startTime=2025-10-01T00:00:00%2B11:00&endTime=2025-10-03T00:00:00%2B11:00

Example Response

{
    "requestStatus": {
        "success": true,
        "version": "v1"
    },
    "sessions": [
        {
            "id": 2788078,
            "productCode": "PWQF1Y",
            "startTime": "2021-09-30T23:00:00Z",
            "endTime": "2021-10-01T02:00:00Z",
            "startTimeLocal": "2021-10-01 09:00:00",
            "endTimeLocal": "2021-10-01 12:00:00",
            "allDay": false,
            "seats": 50,
            "seatsAvailable": 48,
            "priceOptions": [
                {
                    "price": 250.0,
                    "label": "Adult",
                    "id": 929159,
                    "seatsUsed": 1,
                    "productCode": "PWQF1Y"
                },
                {
                    "price": 200.0,
                    "label": "Student",
                    "id": 929160,
                    "seatsUsed": 1,
                    "productCode": "PWQF1Y"
                }
            ]
        },
        {
            "id": 2788381,
            "productCode": "PWQF1Y",
            "startTime": "2021-10-01T23:00:00Z",
            "endTime": "2021-10-02T02:00:00Z",
            "startTimeLocal": "2021-10-02 09:00:00",
            "endTimeLocal": "2021-10-02 12:00:00",
            "allDay": false,
            "seats": 50,
            "seatsAvailable": 50,
            "priceOptions": [
                {
                    "price": 250.0,
                    "label": "Adult",
                    "id": 929159,
                    "seatsUsed": 1,
                    "productCode": "PWQF1Y"
                },
                {
                    "price": 200.0,
                    "label": "Student",
                    "id": 929160,
                    "seatsUsed": 1,
                    "productCode": "PWQF1Y"
                }
            ]
        }
    ]
}

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 price, the next step is a checkout flow.

When a customer selects a specific time and checks out, you should verify real-time availability of the chosen session. Similarly, as the step above, except startTimeLocal and endTimeLocal will be set as the customer's chosen time. In the example we assume customer selecting a tour starting at 9:00 am local time on the 1st of October.

GET https://api.rezdy-staging.com/v1/availability?apiKey=5f4b36ff169047a4a5682cba7e07fea4&productCode=PWQF1Y&startTimeLocal=2025-10-01 09:00:00&endTimeLocal=2025-10-01 09:00:00

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 November 3rd at 9:00AM in Sydney, with a manually processed payment recorded. That means you charged the customer outside Rezdy, on your own website/gateway. You record that payment in the booking for a record keeping purpose only, but Rezdy will not process any payment in this case.

Example Request

POST https://api.rezdy-staging.com/v1/bookings?apiKey=5f4b36ff169047a4a5682cba7e07fea4

{
    "customer": {
        "firstName": "Rick",
        "lastName": "Sanchez",
        "phone": "+61484123456"
    },
    "items": [
        {
            "productCode": "PWQF1Y",
            "startTimeLocal": "2025-10-01 09:00:00",
            "quantities": [
                {
                    "optionLabel": "Adult",
                    "value": 1
                }
            ]
        }
    ],
    "payments": [
        {
            "amount": 250,
            "type": "CASH",
            "recipient": "SUPPLIER",
            "label": "Paid in cash to API specification demo company"
        }
    ]
}

Update booking

PUT /bookings endpoint allows you to amend or provide additional information to an existing booking.

The example below updates the comments, customer pickup location and participant booking fields.

Example Request

PUT: https://api.rezdy-staging.com/v1/bookings/R0A1D6U?apiKey=5f4b36ff169047a4a5682cba7e07fea4

{
    "comments": "Here come comments that are visible to you, but not to customers",
    "orderNumber": "R0A1D6U",
    "status": "CONFIRMED",
    "supplierId": 13398,
    "supplierName": "API specification demo supplier (DO NOT EDIT)",
    "supplierAlias": "apispecificationdemosupplierdonotedit",
    "customer": {
        "id": 29857,
        "firstName": "Rick",
        "lastName": "Sanchez",
        "name": "Rick Sanchez",
        "phone": "+61484123456"
    },
    "items": [
        {
            "pickupLocation": {
                "locationName": "Divers hotel"
            },
            "productName": "Double dive with sharks",
            "productCode": "PWQF1Y",
            "startTime": "2025-09-30T23:00:00Z",
            "endTime": "2025-10-01T02:00:00Z",
            "startTimeLocal": "2025-10-01 09:00:00",
            "endTimeLocal": "2025-10-01 12:00:00",
            "quantities": [
                {
                    "optionLabel": "Adult",
                    "optionPrice": 250.0,
                    "value": 1
                }
            ],
            "totalQuantity": 1,
            "amount": 250.0,
            "extras": [],
            "participants": [
                {
                    "fields": [
                        {
                            "label": "First Name",
                            "value": "Rick"
                        },
                        {
                            "label": "Last Name",
                            "value": "Sanchez"
                        },
                        {
                            "label": "Certification level",
                            "value": "Open Water"
                        },
                        {
                            "label": "Certification number",
                            "value": "123456798"
                        },
                        {
                            "label": "Certification agency",
                            "value": "PADI"
                        }
                    ]
                }
            ],
            "subtotal": 250.0
        }
    ],
    "totalAmount": 250.0,
    "totalCurrency": "AUD",
    "totalPaid": 250.0,
    "totalDue": 0.0,
    "dateCreated": "2021-09-17T01:03:34Z",
    "dateConfirmed": "2021-09-17T01:03:34.298Z",
    "datePaid": "2021-09-17T01:03:34.298Z",
    "payments": [
        {
            "type": "CASH",
            "amount": 250.0,
            "currency": "AUD",
            "date": "2021-09-17T01:03:34.303Z",
            "label": "Paid in cash to API specification demo company",
            "recipient": "SUPPLIER"
        }
    ],
    "fields": [
        {
            "label": "Barcode",
            "value": "R0A1D6U"
        }
    ],
    "source": "API",
    "vouchers": [],
    "barcodeType": "QR_CODE"
}

Cancel booking

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

Example Request

DELETE https://api.rezdy-staging.com/v1/bookings/R0A1D6U?apiKey=5f4b36ff169047a4a5682cba7e07fea4

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

Typical flow with 2 steps booking process follow these steps:

1. create a reservation: call Rezdy API to create a reservation (an order with PROCESSING status) upon a customer cart checkout. This will create an order, which holds reserved product's session's availability for at least 60 minutes or until cancelled.
2. confirm/cancel it: process customer 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.

Example requests to do a 2 steps booking are similar to a standard create and update booking, the only difference is how we set a field status

Create a reservation - a booking in the PROCESSING status:

POST https://api.rezdy.com/v1/bookings/?apiKey=69f708868ddc45eaa1f9b9fad1ddeba5

{
    "status": "PROCESSING", 
    "customer": {
    ...	
}

Confirm a reservation - update the booking RKM1ULT to CONFIRMED status:

PUT https://api.rezdy.com/v1/bookings/RKM1ULT/?apiKey=69f708868ddc45eaa1f9b9fad1ddeba5

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

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 customer 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 RKM1ULT to CANCELLED or ABANDONED_CART status, the later option will cause the order to be hidden from UI screens:

PUT https://api.rezdy.com/v1/bookings/RKM1ULT/?apiKey=69f708868ddc45eaa1f9b9fad1ddeba5

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

RezdyPay payment gateway uses Stripe as an underlying payment provider to process payments though Rezdy platform account, setting your Stripe account as a charge destination using Stripe Charge API. Therefore, you will need to implement an extra call directly to Stripe, before calling Rezdy Booking API.

Charge flow

Use the following 2 calls booking flow:

1. Request a Stripe card token, by sending the customer’s credit card details directly from the customer's browser to Stripe.

You must use a client-side library (Checkout, Elements, or mobile libraries) to perform this process, client-side. You must NOT use the Stripe API. Use Rezdy’s Stripe publishable key (see below) in your request, for the token to be generated on Rezdy’s account. The card is not charged at this stage.

Rezdy’s Stripe publishable keys are:

Staging environment: pk_test_51KW8A8ItvA6u4On8YM6AE95ytcqBr0LeRBEEFw4f5MDQPTDBWVt2TAWXhfynCn7NUVwaGc2eP431DNCkmfMaB0AF00firEVJ58  
Production environment: pk_live_51H4gSPHO6p5n6bFnuGRLb84FCiptIUAwmgYaBubvp5A09HujFx54ExvLkXOufEcqrHsaCWvnmZfO33efkIFVbpIv00PkoJDRDA  

Staging environment keys are usable on api.rezdy-staging.com. Production environment key must be used on api.rezdy.com.

2. Call POST /bookings service, but do not include any booking payments data. You must instead send a creditCard.cardToken parameter that is Stripe’s generated token (id field from Stripe’s API response). Rezdy will confirm the booking, consume the token by processing the payment and record payment on the booking object.

{    
    ...
    "creditCard": {
        "cardToken": "tok_1234zczx9xyzbkBzxcNoabcdef"
    }
    ...
}

There are 3 modes how a product tours can be scheduled in Rezdy, they are called booking modes. It's necessary to take into account the differences between them, for displaying a product availability and making a booking using public API.

These 3 booking modes are:

1. NO_DATE Do not ask for any date (I.e. open tickets valid 6 months from purchase date)
2. DATE_ENQUIRY Require a date but the customer can choose any. There's no availability check.
3. INVENTORY Require pre-populated availability (date+time)

NO_DATE

In case of the NO_DATE products, there is no need to specify booking date and time in a booking request. (However there won't be an error if the startTime or startTimeLocal is specified in a booking request, it just won't be used)

We generate a fake session for the NO_DATE products into GET /availability response, the session startTimeLocal will be midnight and there will be always 999 seats available:

"startTimeLocal": "2016-07-01 00:00:00",  
"seats": 999,  

DATE_ENQUIRY

For the DATE_ENQUIRY products, the booking date and time is required, however there can be any booking date specified. For a booking time, it's a bit more tricky. Those products can be configured to accept any time or just predefined times. How to recognize, if any time is accepted?

We generate a session for DATE_ENQUIRY products into GET /availability response. If the product accept the any time booking, the session startTimeLocal will be a midnight - 00:00:00 time. Otherwise there will be a session for each predefined time.

Availability response - the DATE_ENQUIRY product, which accepts any time booking:

"startTimeLocal": "2016-06-01 00:00:00",  
"seats": 999,  

Availability response - the DATE_ENQUIRY product with predefined list of booking times (7:00 and 9:00 a.m.):

{
    "startTimeLocal": "2016-05-31 07:00:00",  
    "seats": 999,  
    ...
},  
{ 
    "startTimeLocal": "2016-05-31 09:00:00",  
    "seats": 999,  
    ...
}

INVENTORY

This mode is used by most of the products. It means the availability is defined by scheduled sessions. The booking date and time have to match a session startTime.

GET /availability response of INVENTORY mode products, will contain the list of scheduled sessions with a start time and seats available as the supplier scheduled:

"startTimeLocal": "2016-07-01 09:00:00",  
"seats": 20,  

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/v1/products/marketplace?apiKey=69f708868ddc45eaa1f9b9fad1ddeba5&search=PWQF1Y 

RESPONSE:

{  
  "requestStatus": {  
    "success": true,  
    "version": "v1"  
  },  
  "products": [  
    {  
      "productCode": "PWQF1Y",  
      "pickupId": 475,  
...  

To retrieve configured pickup for the product, with a list of all pickup location, call the service method below:

https://api.rezdy-staging.com/v1/products/PWQF1Y/pickups?apiKey=69f708868ddc45eaa1f9b9fad1ddeba5

RESPONSE:

{
    "requestStatus": {
        "success": true,
        "version": "v1"
    },
    "pickupLocations": [
        {
            "locationName": "Divers hotel",
            "address": "Cape Byron, Byron Bay NSW, Australia",
            "latitude": -28.6473671,
            "longitude": 153.601977,
            "minutesPrior": 30,
            "additionalInstructions": "Please be ready 15 minute before the pickup time in the hotel lobby area."
        },
        {
            "locationName": "Seaside hostel",
            "address": "Main Beach, Byron Bay NSW, Australia",
            "latitude": -28.6412831,
            "longitude": 153.6166691,
            "minutesPrior": 20,
            "additionalInstructions": "Please be ready 15 minute before the pickup time in front of the hostel."
        }
    ]
}

To specify a pickup location for a booking, you just need to send one locationName field value of one of the locations from pickupLocations list.

POST https://api.rezdy-staging.com/v1/bookings?apiKey=69f708868ddc45eaa1f9b9fad1ddeba5

REQUEST:

{  
    "items":  
    [  
        {  
            "productCode": "PWQF1Y",  
            "startTimeLocal": "2025-08-11 14:00:00",  
            "quantities":  
            [  
                {  
                    "optionLabel": "Adult",  
                    "value": "1"  
                }  
            ],  
            "pickupLocation":  
            {  
                "locationName": "Divers hotel"  
            }  
        }  
    ]
    ... 
}  

System will store the pickup location, calculate pickup time and return the pickup instructions.

RESPONSE:

{  
  "requestStatus": {  
    "success": true,  
    "version": "v1"  
  },  
  "booking": {  
    "orderNumber": "R3MPR7Z",  
    ...  
    "items": [  
      {  
        "productName": "DEMO - One day SCUBA diving",  
        "productCode": "PKVT0E",  
        "startTime": "2016-07-11T04:00:00Z",  
        ....  
        "pickupLocation": {  
          "locationName": "Maroubra Beach",  
          "address": "Maroubra Beach, New South Wales, Australia",  
          "pickupTime": "2016-07-11 13:05:00",  
          "pickupInstructions": "In front of the Maroubra seal surfing club building.\r\nPlease be ready 15 minutes before pickup time."  
        }  
      }  
    ],  
    ....  

It is also possible to specify a custom pickup location (should be discussed with the product supplier if this option is feasible):

REQUEST:

{  
    "items":  
    [  
        {  
            "productCode": "PWQF1Y",  
            "startTimeLocal": "2025-08-11 14:00:00",  
            "quantities":  
            [  
                {  
                    "optionLabel": "Adult",  
                    "value": "1"  
                }  
            ],  
            "pickupLocation":  
            {  
                "locationName": "Hotel by the sea"  
            }  
        }  
    ]
    ... 
}  

In this case system stores the pickup location (naturally, it can't calculate the other fields like pickup time or address) and returns the custom pickup location instructions (if specified by the supplier).

RESPONSE:

{  
  "requestStatus": {  
    "success": true,  
    "version": "v1"  
  },  
  "booking": {  
    "orderNumber": "R3MPR7Z",  
    ...  
    "items": [  
      {  
        "productName": "DEMO - One day SCUBA diving",  
        "productCode": "PKVT0E",  
        "startTime": "2016-07-11T04:00:00Z",  
        ....  
        "pickupLocation": {  
            "locationName": "Hotel by the sea",
            "pickupInstructions": "Call us on +61123456 to arrange a pickup from a custom pickup request not listed among the pickup locations.\r\nPlease be ready 15 minute before the pickup time."  
        }  
      }  
    ],  
    .... 

Please note that we are now enforcing validations on Booking Fields that are being sent through our API. Not only the mandatory fields, but also the format matching their type.

Booking Field Types

Every booking field has a certain type (see bookingFields.fieldType) and their value has to be formatted accordingly. An exception is a string, when the booking field value is a free text.

The bookingFields.fieldType is one of:

• String
• Phone
• List
• Date
• Boolean

The following booking field types need to have specific values.

Boolean

This field must contain a boolean value. Accepted values are 1, 0, TRUE, FALSE, YES, NO (case insensitive matching)

{
    "label": "I agree to receive marketing emails",
    "value": "true"
}

Date

This field must be a ISO-8601 date only format yyyy-MM-dd e.g. 1991-01-01

{
    "label": "Date of Birth",
    "value": "1991-01-01"
}

Phone

This field must be in an international format +41 44 668 18 00, or E164 format +41446681800

{
    "label": "Mobile",
    "value": "+61484123456"
}

List

List types need to match one of the predefined values, common list types are the following:

Country

This field must be in ISO 3166-1 alpha-2 codes format e.g. Australia -> au, United States -> us (case insensitive matching)

{
    "label": "Country",
    "value": "AU"
}

Gender

Valid genders that are accepted through our API will be: MALE and FEMALE. (case insensitive matching)

{
    "label": "Gender",
    "value": "MALE"
}

Title

Valid titles that are accepted through our API will be: MR, MS, MRS, MISS. (case insensitive matching)

{
    "label": "Title",
    "value": "MISS"
}

You are able to suppress Rezdy's notifications to customers when creating or cancelling a booking. You can then send emails & SMS from your own system instead.

To disable them, send the flag "sendNotifications" = "false" in the booking object in POST /bookings e.g.:

{
    "customer": {},
    "items": [],
    "sendNotifications": false
}

The flag is only used per request and is not stored.

To suppress notifications when cancelling a booking, you must set it as query parameter in the cancellation request:

DELETE /bookings/{orderNumber}?sendNotifications=false

It is not possible to disable Rezdy's notifications to suppliers and agents. Only the customer notifications can be disabled.

Note: Rezdy emails may include QR codes (if enabled by supplier), which suppliers can use to check-in participants using our mobile apps, see (QR Code Scanner ). If you decide to use your own emails, the booking QR code should be included in the e-mails. The QR code is the Rezdy orderNumber.

The Rezdy API does not expose internal product Ids. You can only use Rezdy-generated product codes, which always start with P, e.g. PVGNQX. However, booking forms use internal product Ids in booking page URLs and widgets, e.g. https://demo-booking-form.rezdy.com/124318/amazing-day-tour

If you need to load product data from the API and then link to the booking form for checkout, you can use the product codes. These 2 URLs will load the same page:

https://demo-booking-form.rezdy.com/124318/amazing-day-tour

https://demo-booking-form.rezdy.com/view/PVGNQX

You can therefore use API product codes for booking form product pages, by using this url:

https://{alias}.rezdy.com/view/{productCode}

2023-03-31

Added new error codes

2022-08-29

In order to support automated commissions payout via Stripe recipient only account, RezdyPay on staging environment has switched to a new US-based Stripe test account, and the Stripe publishable key for staging environment has changed. The key for production environment remains the same.

Staging environment: pk_test_51KW8A8ItvA6u4On8YM6AE95ytcqBr0LeRBEEFw4f5MDQPTDBWVt2TAWXhfynCn7NUVwaGc2eP431DNCkmfMaB0AF00firEVJ58

2021-08-30

Rezdy API specification split into agent and supplier portal.

2021-01-03

RezdyPay payment gateway has been upgraded and Rezdy uses a new Stripe platform account, to process automated payment bookings, or manual payment bookings with credit card charged though RezdyPay. As a result, new publishable keys need to be used to create a Stripe token.

Staging environment: pk_test_5nODbTMiGQCMOHg0Nt5LzQUV00CcWuIksX  
Production environment: pk_live_51H4gSPHO6p5n6bFnuGRLb84FCiptIUAwmgYaBubvp5A09HujFx54ExvLkXOufEcqrHsaCWvnmZfO33efkIFVbpIv00PkoJDRDA  

More details are in RezdyPay payments processing article

2021-01-28

• New product isApiBookingSupported field has been added to Product response model.

It provides a convenient way to find out if a product booking is supported via API. Some product types or pricing types or their combinations are not supported in API. If you are planning to implement a booking flow via API, you should filter out the products, if the value of this field is set as false.

2020-11-17

• Order level barcodes are now supported, this will always be present as an element in the fields attribute of the Booking model.

  {
    "orderNumber": "R12345",
    ...
    "fields": [
        {
            "label": "Barcode",
            "value": "6000125341"
        }
    ]
  }
  

2020-11-02

• POST /products/{productCode} and PUT /products/{productCode} can now create "Hidden" booking fields. Hidden booking fields will not be shown to the customer during the booking and are intended for internal use.
• See Create Product Request and Update Product Request

2020-09-24

• POST /products/{productCode} and PUT /products/{productCode} now has the ability to determine how to output barcodes when a booking is created for that product. This can be achieved by populating the barcodeOutputType field. Current values support are:
  • PARTICIPANT: Barcodes will be generated per participant when the product has been booked
  • ORDER: Barcodes will be generated only for the order when the product has been booked
• See ResponseProduct for more field description

2020-08-24

• GET /bookings/{orderNumber} now returns barcodeType which specifies the format in which the booking barcodes are in. Rezdy supports "TEXT", "QR_CODE", "CODE_39", "CODE_128", "EAN_8", "EAN_13", "ITF".

2020-06-16

• A booking reseller and a supplier can use PUT /bookings/{orderNumber} to update resellerReference and pickup locationName fields

2020-04-02

• Updating product price options are now possible through the PUT /products/{productCode} endpoint

2020-02-10

• RezdyConnect specification is no longer part of Public API, it has been upgraded and moved to RezdyConnect (2.0.0) portal

2019-10-30

• Product update service now supports internalCode update

2019-09-30

• Bookings search by resellerReference field

2019-08-28

• Agents are allowed to update resellerReference field in PUT /bookings/{orderNumber}

2019-07-04

• Added an article describing booking flow for RezdyPay payments bookings

2019-07-03

• Api key can be send as HTTP header named apiKey instead of a query parameter e.g. apiKey: abcd123

2019-03-28

• New fields have been exposed in Product responses including:
  • qrCodeType
  • waitListingEnabled
• See ResponseProduct for more field description

2019-02-29

• We are introducing a new Staging environment and deprecating our Test environment api.rezdy-test.com. We encourage usage of the new Staging environment which will be more stable than the old test environment and will soon support data replication from our Production environment.

  • Login: https://app.rezdy-staging.com
  • API root URL: https://api.rezdy-staging.com
  • API spec.: https://developers.rezdy-staging.com

  See Environments section in API overview for details

2019-02-25

• Booking search service now supports filtering by date created Please note that the createdSince parameter has been deprecated. Use minDateCreated to include bookings that were created after or on this date. Use maxDateCreated to include bookings that were created before or on this date.
• Booking responses will now show Supplier Alias and Agent Alias.

2018-11-29

• Booking search service now includes bookings in PROCESSING status in the result list.
  The PROCESSING status can be used in a supplier's API integration for 2 steps booking process, when a temporal reservation is created to hold availability.
  The PROCESSING bookings are normally released after 60 minutes, if they are not confirmed.
  

2018-11-28

• New Extra CRUD endpoint and service. A product now can have Extras added to it.
  

2018-11-20

• New product configurations supported in the product create service, including custom booking field types and product fixed price.
  See updated [Create products article](#operation/createProduct)
  

2018-10-15

• You should now use the same Stripe publishable key for all currencies, when generating tokens for automated payments. We will accept old keys until at least until 30 November 2018, but please migrate to the new keys below:

  TEST: pk_test_wGcSehTxQDTLoMRVl6Gv45zy
  PROD: pk_live_zKs28ywqmpH5K6Vz9moNGwiM

2018-08-22

• New fields supported in product update service including confirmMode, confirmModeMinParticipants, minimumNoticeMinutes, durationMinutes
  

2018-07-16

• New endpoints for [creating](#operation/createPickupList), [updating](#operation/updatePickupList) and [retrieving](#operation/getPickupList) pickup lists accompanied by a new [PickupList](#operation/getPickupList) model
  

  • Added support for setting a pickup for a product through creating and updating products. To add a pickup list to a product simply:
    

    • 1. Create a pick up list
      

      • 2. Specify the pickupId in [ProductCreateRequest](#operation/createProduct) and [ProductUpdateRequest](#operation/updateProduct)
        

        • All taxes and fees applied to a booking item will be now exposed through the totalItemTax field as part of the Booking "items" field.
          

          • Added support for taxes/fees associated with a specific product. This field is available through [get product](#operation/getProduct)
            

2018-06-21

• Validation for booking field types such as Date of birth, Country, Gender, Title, Marketing are now enforced. Those values that do not comply will not be saved, but rather be appended to the booking comments.
  See [the expected booking fields format](#operation/createBooking)
  

2018-06-20

• Product cancellationPolicyDays field will now only be shown for marketplace products.
  

  • Product cancellationPolicyDays for products that are shared between agents with AUTOMATED payments will still be shown
    

2018-06-06

• New product tag filters for search marketplace products **(Check Agent API Portal)**. The product tags are part of the product model and can be retrieved via product search/get services.
  

2018-01-29

• New endpoints for suppliers to manage product rates

2017-12-14

• Product update service now supports updating product terms & conditions

2017-11-15

• New field resellerReference added to booking object. It is designed to hold the booking number in an agent system, when it is different from the Rezdy booking number.

2017-10-04

• New endpoints for suppliers to get and set RezdyConnect configuration for a specific product
• Added visible query parameter to GET /categories to filter public/private categories

2017-10-01

• Test API endpoints have changed to be more consistent with our production environment:
  • old URL: https://api-test.rezdy.com
  • new URL: https://api.rezdy-test.com
• In accordance with Stripe's PCI Compliance requirements, Stripe tokens generated to process Automated payments must use a client-side library. You must use Checkout, Elements, or mobile libraries to perform this process, client-side. Tokens generated via API will no longer be accepted.

2017-09-29

• Allow PUT /bookings/{orderNumber} to update resellerComments field

2017-01-19

• Added services to create and update products:

  • create a product: POST /products
  • delete a product: DELETE /products/{productCode}
  • add a product image: POST /products/{productCode}/images
  • delete a product image: DELETE /products/{productCode}/images/{imageId}

  More details in this article.

• Added information about visible – optional product booking fields: "visiblePerParticipant": true|false, "visiblePerBooking": true|false to BookingFields model

• Booking update, for manual payment bookings. Currently, these fields can be updated using the API:

  • customer – all customer data can be updated
  • "per order" booking fields – all values can be updated, added or deleted
  • "per participant" booking fields – all values can be updated, added or deleted
  • order status – only supplier’s for suppliers

  More details in this article.

2016-12-12

• Search products by languages

2016-11-01

• Supplier’s promocodes and vouchers redemption supported in a booking request and quote calculation

2016-10-17

• Added new field commissionIncludesExtras to Product – Flag if agent receive commission from extras, or not

2016-09-28

• Support for agent payments (Check Agent API Portal) for automated payments agents bookings – all payments in the booking request, will reduce the agent commission.
• Support for agent price override (Check Agent API Portal) for automated payments agents bookings – if the item amount is specified, the agent commission is adjusted by the difference between the catalog and agent price.

2016-09-26

• Added product additionalInformation to Product data model – Additional information for the product, that should be sent after a booking is completed (i.e. by email) to the customer. Useful for integration, when manual control of the entire customer booking experience is wanted, and the automatic confirmation e-mail from Rezdy had been suppressed.

2016-09-13

• Automated payments agents bookings, now show Commission without Rezdy Fee in the response.

2016-09-01

• sendNotifications field is now supported in DELETE /bookings/{orderNumber} too
• added new search parameter updatedSince to GET /bookings – Only load bookings updated after this time

2016-08-22

• Added new fields to show links between Vouchers and Orders.
  • GET /bookings shows the voucher numbers + statuses, that were generated when the order was created and created gift card.
  • GET /vouchers shows the "source" order of the voucher.

2016-06-22

• Removed the "3 months max range" rule when requesting availability.
• Default pagination limit increased to 100 instead of 30 in all search services using pagination

2016-05-24

• Pickups support:
  • Added new service method GET /products/{productCode}/pickups to list pickup locations.
  • Added pickupLocation to BookingItem data model, to specify the pickup location name when creating a booking and display pickup address, time and instructions in the booking response.
• Added product locationAddress to Product data model.

2016-04-27

• Added new fields value and valueType to Voucher data model.

2016-04-04

• TRANSFER product types without return can be booked through the Public API

2016-02-22

• Added new Company endpoint with service:
  • GET /companies/{companyAlias} – Retrieve Company details by it’s alias
• Added minimumNoticeMinutes field to Product data model – Minimum book ahead interval for the product in minutes.

2016-02-15

• Added new Resources endpoint with services:

  • GET /resources – Retrieve all supplier resources.
  • GET /resources/session – Retrieve resources assigned to the session.
  • GET /resources/{resourceId}/sessions – Retrieves all sessions for a specified resource within the start/end datetime range.
  • PUT /resources/{resourceId}/session/{sessionId} – Add a resource to a session.
  • DELETE /resources/{resourceId}/session/{sessionId} – Removes a resource from a session.

• New service methods in Manifest endpoint:

  • PUT /manifest/checkinSession – Store Check-in / No show flag for everyone in a specified session.
  • PUT /manifest/checkinOrderSession – Place Check-in a / No show flag for the specified order item.
  • DELETE /manifest/checkinSession – Remove Check-in / No show flag from everyone in the whole session.
  • DELETE /manifest/checkinOrderSession – Remove Check-in / No show flag for the specified order item.

• Added duration fields to Product data model

• Support of orderStatus field in supplier’s Booking request

2016-02-01

• Added localized date/time fields: startTimeLocal and endTimeLocal can be used to search and display availability in the supplier’s timezone.
• Added new fields to Product data model: dateCreated and dateUpdated. Also added updatedSince attribute to GET /products/marketplace (Check Agent API Portal) endpoint
• Added new fields to Product data model when calling GET /products/marketplace (Check Agent API Portal) as an agent: cancellationPolicyDays. This is only used for Automated Payments (agentPaymentType = PAYOUTS)
• Added search by supplierAlias to GET /products/marketplace (Check Agent API Portal) endpoint
• Added automatic refund when canceling an Automated payments booking

2015-11-23

• Added support for DATE_ENQUIRY and NO_DATE booking modes for /availability and /bookings calls. When calling /availability for these products, one session per day will always be returned.
• Added new fields to Product data model: confirmModeMinParticipants
• Added new fields to Product data model when calling GET /products/marketplace (Check Agent API Portal) as an agent: agentPaymentType, maxCommissionPercent, maxCommissionNetRate

2015-07-27 – Marketplace release

• The API service /products/partners has been deprecated and replaced by a new service /products/marketplace (Check Agent API Portal) with many more filters.
• Some constants were renamed, especially Order source PARTNERS to MARKETPLACE_PREF_RATE, and COMMUNITY to MARKETPLACE.

2015-07-13

• Added support for multiple product codes to the GET /availability endpoint. Use "&productCode=P11111&productCode=P22222&productCode=P33333" to request availability for multiple products in the same request

2015-06-10

• Added images to Extras

2015-04-20

• New endpoint to validate a booking and calculate totals before it’s created: POST /bookings/quote
• Added support for Credit Card payments to the POST /bookings endpoint
• Fixed incorrect min/max quantities for DOUBLE, TRIPLE and QUAD price options

2015-03-30

• Fix an issue with FREE_SALE products. They now always return 999 seats and seats available
• Fix offset and limit not working for the GET /categories/{id}/products endpoint
• Added support for Product codes in Rezdy-hosted booking forms. The following URLs now load the same page:
  • https://rezdydemo.rezdy.com/35867/demo-sydney-bike-tour
  • https://rezdydemo.rezdy.com/view/PVO39Z

2015-03-16

• Fix an issue with mandatory fields required "once per booking".

2015-03-02

• Added currency attribute to products

2015-02-02

• Fix group price options. Use correct label and show min/max participant values for each group price.

2015-01-19

• New Category endpoint to load categories and products within categories. 3 new services are available:
  • GET /categories
  • GET /categories/{categoryId}
  • GET /categories/{categoryId}/products

2014-12-17

• Added new attributes to filter the GET /bookings results. You can now filter by product, booked date, and only load new bookings created since a set date.

##2014-12-01

• Added validation and fixed issues with product Extras when making a new booking

2014-11-17

• Order source has been deprecated for new booking requests. Bookings created by API will now always have source=API. Availability will always be checked for API bookings and minimum bookahead rules will always be enforced. Mandatory fields will not be enforced for supplier bookings.
• You can now use Booking.sendNotifications (true/false, default true) to control if automated notifications should be sent to the customer or not when making a new booking through the API.
• New Availability endpoints for suppliers: Create/Delete/Update availability
• Added pagination to calls that return multiple items. Defaults to 30 results, max 100 per request

2014-11-03

• Added timezone to Product resource (Product.timezone)
• Added supplier general terms and conditions to Product resource (Product.generalTerms)
• New Booking endpoint: DELETE /bookings/{orderNumber} will cancel a booking
• Updated documentation

2014-07-15

• Added supplierId attribute to /products/partners to filter products by supplier
• Simplify price option and quantity mapping when making bookings
• Added confirmation mode to Product resource (Product.confirmMode)