Best Available Flow

Redeam carried out some research and determined that not all Resellers are able to handle seat distribution, but instead use the Best Available Flow in order to support seated events. When using the Best Available flow, the best available seats on the relevant price level and product option are selected and assigned by the ticketing system. Many Resellers need manual steps to set up live event products and Redeam would like to help with their distribution through a streamlined process flow.

In order to facilitate the Best Available process flow, Redeam developed a way to have live events work with the Standard "attraction" model which means the Reseller can use their current workflow (Get Supplier - Get Products - Get Rates - Get Price Schedule - Get Availabilities)

Please note that seats will be contiguous using this flow, it even takes venues into consideration which only use even (2, 4, 6, etc.) or odd (1, 3, 5, etc.) numbered seats. Whenever the ticketing system cannot find the requested number of seats next to each other, it will return a failed response.

Inventory Setup & Organization

Redeam works with Suppliers to understand the different data structures and configurations and takes care of them:

  • Data configurable grouping logic used to set up all Supplier and product type scenarios
  • Mapping for areas, sections, prices within a venue and organizes them into product options / rates

By covering the above items it will prevent delays in onboarding and also prevents the Reseller from implementing new functionality. Redeam ensures that when Resellers call the Redeam endpoints, the data is modified and available for caching through the Redeam Booking API.

Depending on the connection, here are some different setup scenarios:

  1. Attractions → Contract with Caesars to sell High Roller (Venues): Caesars would be the supplier and the products would be representative of various venues

    1. Supplier: Caesars Entertainment
    2. Products: Fly LINQ Zipline at THE LINQ, High Roller Wheel at The LINQ (general admission/attraction products)

  2. Resident Live Events → Contract with Caesars to sell multiple resident shows (Attraction) → Caesars would be the supplier with multiple attractions as the products

    1. Supplier: Caesars Entertainment
    2. Products: Donny Osmond, Menopause The Musical (live events / seated products)

  3. Sporting Live Events → Contract with Orlando Magic (Attractions) - 2 Attractions, 1 Venue: Orlando Magic are Supplier and product

    1. Supplier: Orlando Magic
    2. Product: Orlando Magic (home games only)
    3. Availabilities: home games dates with opponent name details under each date (Orlando Magic the first attraction, opponent team the second attraction)

  4. Touring Live Event → Contract with Live Nation - 1 Attraction, Multiple Venues, 1 Promoter (Attraction + Venue): each combination of attraction date + venue would be a different product

    1. Supplier: Live Nation Music
    2. Products: Thirty Seconds To Mars - Seasons World Tour @ Pine Knob Music Theatre, Thirty Seconds To Mars - Seasons World Tour @ Xfinity Center, Thirty Seconds To Mars - Seasons World Tour @ Barclays Center (attraction name + venue name)
    3. Availabilities: each product will have it's own availability details

Redeam Endpoints & Extra Data Sharing

The Reseller should use the standard Redeam endpoints flow to get inventory data, however, there are some new extension keys we recommend you to implement in order to help with the data setup and display in your UI.

Extensions allow the Reseller or Supplier to provide additional data to Redeam or the partner system whenever there is no specific field in the specification. For more information, please refer to Extensions.

Resellers may find this field in the JSON as “ext" or the full word "extensions". Please note they share the exact same function.

GET Suppliers

This endpoint mapping data will keep the same data structure as outlined in the Suppliers page . The schema can be used for attractions as well as live events / seated events.

GET Products

The structure for this endpoint outlined in the Products page is also for live events, however, some additional data is shared through extensions keys. They are not mandatory but could be very helpful information for Resellers to differentiate products, therefore their implementation is highly recommended.

  • Availability Pricing Type

This key can be found under product extensions - product.extensions.beta-availabilityPricingType. The flags help the Reseller to identify different types of products and if a different flow is applicable.

ATTRACTION - represents the general admission product types

BEST_AVAILABLE - live events products using the flow with the same name

SEATING - corresponds to the products using the SCAP (Seat Chart Pricing & Availability) flow, which is the specific seat distribution flow with all areas, rows and seat details. This flow requires additional endpoint calls for granular level of data.

  • Safetix Product ( Ticketmaster connection-specific)

The ticketmaster.SafetixProduct extension key on the product level is specific to the Ticketmaster ticketing system connection (this is why the prefix is ticketmaster not beta). This boolean field allows the Reseller not only to identify whether a product is a Ticketmaster Safetix event or not but also determine its corresponding communication and redemption description.

If true, the Reseller will not receive a static barcode for the booking from Redeam like for other products but instead the response: tickets.barcode.format = URL and tickets.barcode.value = URL link to the Ticketmaster login page

If false, Redeam will deliver the static barcode value with the corresponding format indicated in tickets.barcode.format field (possible values: CODE128,CODE39,EAN13,QR_CODE,TEXT,UPCA, INTERLEAVED)

Note: if you require additional information on Safetix events, please ask your Redeam contact to share the Safetix Product Redemption flow documentation with you.

Example of GET Product response:

Get Product response
Copy

GET Rates

The endpoint response details can be found in the spec under the Rates page with info on additional data shared through extensions keys.

  • Minimum & Maximum Travelers

Both are existing fields in the Redeam API that are important in live events bookings. They represent the minimum and maximum number of travelers defined to qualify for a rate, in other words the minimum and maximum number of tickets that can be purchased. The data is mapped from the Supplier setup and will prevent customers from selecting more than the allowed quantity and also receiving errors during Hold and Booking requests.

Get Rates response
Copy
  • Restrict Single Seat

The beta-restrictSingleSeat extension key at the Rate level was created to share the indicator if there are restrictions applied to the product rate for seat selections. The flag indicates that no seats can be left unoccupied. Example: if there are 4 seats left and 3 seats are requested, the request fails as it is difficult to sell a single seat in a section. The Supplier specifies this restriction and Redeam expose the value to help Resellers understanding why the hold might be rejected. In order to increase the number of successful holds and receiving the reason for why it failed in case it does, we recommend implementing beta-restrictSingleSeat=true. The number of seats in a hold requests are limited to currentTicketLimit-1 to avoid unknowingly hitting this restriction. Check further details under External Doc - Reseller Best Available Flow | Get Availabilities

Get Rates response
Copy

GET Price Schedule

This endpoint has the same data structure for attractions or seated events as outlined in the Price Schedule page .

GET Availabilities

This API response is still structured as per our Availabilities documentation, however, our recommendation for Resellers is to review the additional data shared in extension keys and to use them to enhance the data presented to the consumer.

  • Current Ticket Limit ( Ticketmaster connection-specific)

This additional extension key in the availability response indicates not only the product rate maxTravelers limit but also what the current ticket limit is set to. maxTravelers does not change as it is defined at product / rate level at its creation and indicates the maximum number of tickets that can be purchased. Whereas ticketmaster.CurrentTicketLimit informs you about the real time inventory at time of a request.

Example: maxTravelers is 8 and the ticketmaster.CurrentTicketLimit is 4 at the time an availability call is made, therefore any ticket quantity higher than 4 will fail.

Get Availabilities response
Copy
  • Event Name ( Ticketmaster connection-specific)

Information on this can be found in the availabilities response specific for the Ticketmaster connection. Resellers should expect to get the event name value for each availability object, not a single extension key value at the top level.

Depending on the Ticketmaster event, the name can be different but are grouped under the same product. Example: a sports event uses the host team name under product name and the opponent team name in the extension key ticketmaster.EventName.

Note: the Reseller needs to parse the field to get the desired data, for example Orlando Magic vs Detroit Pistons

Get Availabilities response
Copy
  • Attraction Name

The extension key beta-attractions shares the data for non Ticketmaster connections. Example: for a sports product it provides the opponent name for the Reseller to get details about the game scheduled on that day: New York Yankees vs. Detroit Tigers.

Note: in this case the extension indicates the opponent name for each game day, facilitating a way to consume the data. This extension key will not be returned for Ticketmaster products.

Get Availabilities response
Copy

For both ticketmaster.EventName and beta-attractions if the Reseller is able to attach the data by date the buyer will know the match details for the selected date. Since that information is associated to different dates, we can’t have it prior to the Availabilities call because Supplier, Products and Rates are most likely static data that are cached.

If the Reseller is able to attach the data shared in ticketmaster.EventName and beta-attractions by date, the buyer sees the game details for the selected date. These details get returned in the Availability and can be different depending on the date.

Depending on the date selected, the Reseller can display the opponent team name with the match date and availability. The opponent name is attached to the different areas / sections and price point rates.

Depending on the date selected, the Reseller can display the opponent team name with the match date and availability. The opponent name is attached to the different areas / sections and price point rates.
In this case, the Reseller does not display the opponent team name associated with the match date and availability. The product rates listing is only for the areas / sections and price points

In this case, the Reseller does not display the opponent team name associated with the match date and availability. The product rates listing is only for the areas / sections and price points

Holds and Bookings

There is important data in Holds and Bookings responses which need to be used in the booking confirmation for best available products:

  • Supplier Reference

supplier.reference is an existing field in the Redeam API spec which populates once the booking is confirmed. The Reseller needs to pull the data from this field and place it on the voucher.

supplier.reference key implementation is mandatory
  • Ticket Locations Reference

These details could be shared on both the Redeam Holds and Bookings responses if the Supplier has the information available at that point (which is the case for Ticketmaster). Once the supplier assigns the seats Redeam adds that information in the Hold and Booking response so the Resellers can share it with the buyer. This field reflects the real seats instead of a range of seats since the range could generate confusion in the case of venues with odd or even seat numbers. beta-ticketLocations should be 1 to 1 with the total quantity of the booking, below you can find the structure:

TicketLocations structure
Copy

Please note the beta-seatLocations extension key you see in the Holds and Bookings responses will be deprecated in the future. Therefore, please make sure you have beta-ticketLocations key implemented to cover different scenarios and be more precise with the information shared.
  • Delivery Method

This extension key beta-deliveryMethod is used to map the product delivery format so the Reseller can use it as a reference. A value of TICKET indicates that there is one barcode.value for each ticket in the Booking, a value of VOUCHER indicates that there is one barcode.value which is shared for all tickets in the Booking.

TICKET Type response
VOUCHER Type response
Copy
  • Safetix Text ( Ticketmaster connection-specific)

Note that the barcode.format for Safetix products is URL and the barcode.value is the link from the Ticketmaster API. In addition, Redeam includes an extension key ticketmaster.Safetix with a default text in case the Reseller wants to share additional information with the buyer

Booking response
Copy
Type to search, ESC to discard
Type to search, ESC to discard
Type to search, ESC to discard
Next to read:
Reseller API Best Practice

Questions? We'd love to hear them. Contact Redeam support.

On This Page
Best Available FlowInventory Setup & OrganizationRedeam Endpoints & Extra Data SharingGET SuppliersGET ProductsGET RatesGET Price ScheduleGET AvailabilitiesHolds and Bookings