Bridgify Merchant API

Implementation Guide

Overview

The Bridgify Merchant API provides a unified interface for booking attractions and experiences from multiple attraction suppliers. This allows you to work with a single integration instead of maintaining separate connections for each supplier.

Current suppliers include (but are not limited to): Viator, GetYourGuide, Tiqets, Ticketero, Attraction World, SportsEvents 365, Live Tickets, HotelBeds, GoCity, and Tillo. Additional suppliers are added on a regular basis.

The API supports a wide range of product categories, such as: ● Attraction tickets (museums, zoos, theme parks, amusement parks) ● Guided tours ● Sports events ● Concerts ● City passes ● Gift vouchers for store credits

By using the Bridgify Merchant API, you can access multiple suppliers through one standardized integration, simplifying implementation and reducing maintenance overhead.

Searching for attractions vs. retrieving a single attraction

When you search for attractions through the …/attractions/products endpoint, the response contains only the basic details for each attraction in the results.

When you request a specific attraction using …/attractions/products/[UUID], the response includes the full set of available information for that attraction.

Availability

Attractions can have different types of availability information.

Here are the possible availability types

Supplier Differences

The data supplied about an attraction when searching and when retrieving information about a specific attraction can sometimes differ between suppliers. For example, some suppliers might provide important information in the "important_information" field. Others might include that in the "included_list" and "excluded_list" fields.

While the booking API is unified and works the same for all suppliers, there are some endpoints where the data will differ by supplier. Because of that, it's important to test different types of attractions within each supplier (i.e. guided tours, entry tickets, etc.), and also attractions from each supplier.

Over the course of this document, some important differences will be pointed out.

City Names

There are many city names that are in use for different places worldwide. Sometimes, in places like the USA, the same city name might even exist in multiple US states. When searching for attractions by city name, you will receive results for attractions from the city with that name that has the most attractions. That is almost always the city that's desired.

Where there are multiple cities with the same name and you want results from a specific city, you can search by city id instead of city name. A city id always refers to a single, specific city. You can get the city id from the cities returned by the "cities" API endpoint.

In most cases, if an attraction is not within the city limits of a big city, but is in a small town close to a big city, the city associated with the attraction will be the nearby big city.

Pickup points

Some attractions have "pickup points", which are sometimes called "meeting points". Those are the locations where the attraction operator can pickup the ticket holder and bring them to the attraction location. Pickup points are usually hotels or other central city locations. When going through the booking flow, generally the pickup points will be a list of hotels and the traveler will need be presented that list and choose one.

For Viator, the pickup point selection is sometimes a choice like: Hotel, Port, Select later

In most cases, the pickup point selection is part of the "pickup-point" endpoint. Some attraction suppliers, like GetYourGuide for example, include that as part of the "customer-info" endpoint.

GetYourGuide specific pickup point information

For some ticket suppliers, like GetYourGuide, there can be other types of pickup points (besides a list of location names/choices).

For example, GetYourGuide has 3 different pickup point types:

"list" with geolocation

With Getyourguide "list" pickup points you are also given the geolocations of the pickup points in addition to the name of the hotel/location. That gives you the option to show the locations on a map and allow users to choose a location that way. Or, you can provide a list of the locations and allow the user to choose from the list. In that case you still return the geolocation of the selected location as the pickup point location.

Here is an example of a "list" pickup point being displayed with 3 options that can be selected on the map.

Here is part of an example (not connected to the image above) of what's provided as part of the "customer info" endpoint for "list" pickup points:

"rect" pickup points

With "rect" pickup points, you are given the coordiantes for a single rectangle and the user needs to choose a geolocation from within the rectangle. You provide the API with the selected geolocation.

Here is an example (not connected to the image above) of what's provided as part of the "customer info" endpoint for "rect" pickup points.

"multirect" pickup points

"multirect" pickup points work like "rect" pickup points, but you are provided with more than one rectangle. The user can choose a geolocation from within any of the rectangular areas. Here is an example shown on the map.

Here is an example (not connected to the image above) of what's provided as part of the "customer info" endpoint for "multirect" pickup points:

Here are some examples of what needs to sent as part of the PATCH in order to set the selected pickup point for the ticket.

PATCH example of part of the request body for a "rect" or "multirect" pickup point type:

PATCH example or part of the request body for a "list" pickup point type:

Date and time formats

Dates are set and presented in ISO 8601 format:

For example: 2025-09-09T04:00:39.689329

• 2025 → the year
• 09 → the month (September)
• 09 → the day of the month

So the date part is: 2025-09-09 (September 9th, 2025).

Then comes the letter T, which separates the date from the time.

• 04 → the hour (04:00, in 24-hour format → 4 AM)
• 00 → the minutes (00 minutes)
• 39 → the seconds (39 seconds)
• 689329 → the fractional seconds (microseconds, i.e. 689,329 microseconds = 0.689329 seconds)

In most cases no timezone is included and the timezone is understood by the context. For example, the date/time for a scheduled event or guided tour will be in the local timezone of the event/tour.

Languages

Search

At the current time, search results are available in the following languages: English (default), Hebrew, Italian, Portuguese

The language can be selected by adding the "lang=" query parameter with the 2 character ISO language code.

• English - en
• Hebrew – he
• Italian – it
• Portuguese – pt

Additional languages will be supported in the future.

Booking

In the booking API, most ticket types, error messages, customer info questions will be in English, regardless of the language setting.

User Supplied Attraction Supplier API Credentials

In some situations, it may be necessary to use your own attraction API credentials for a given attraction supplier when booking the attraction. We provide a way to override the usual API credentials used while booking. (We call this “API key overriding.”)

Important Cautions

1. When booking an attraction, the override credentials that you supply must be used for all API calls involved in booking the given attraction.
2. You are fully responsible for any support or issues that might arise with the attractions booking.
   • Bridgify has no way of checking, confirming, or accessing any details of the booking.
   • We have limited ability to provide support if there are booking problems.

How to Use Your Own API Credentials

To use your own API credentials, include the following keys in the request header of each step of the booking process.
Since booking involves multiple API calls, it’s important that the override credentials are used for every API call connected with the booking.

• X-API-Override-Key
  Contains the API key that should be used for the booking.

• X-API-Override-Secret (if required)
  If the attraction supplier also requires a password or “secret” (for example, with OAuth), then include this second header key.