Extensions

The Redeam API provides additional fields called extensions in different locations for data that does not have its own attribute in the spec. Extensions allow the Reseller and Operator to provide additional data to Redeam or to exchange required information between the connecting partners.

The below example includes a cancel policy on the product level:

Example
Copy

This second example shows additional traveler information which could be required for a partner on the booking level:

Example
Copy

Please note that Redeam refer to extensions as “ext" or "extensions" in the JSON. They both share the exact same function

Redeam highly recommend that Resellers implement all of the extensions in order to get required data from the Operator / Ticketing System to have the complete set of information needed for bookings and tickets / vouchers.

Even if they are not required for the first partner connection, additional development can be avoided when onboarding a new partner requiring additional information.

Beta Keys

Redeam make use of extensions to map useful information that have not been added to the spec yet or are still being defined as beta-(key). These keys are identified with the prefix beta- so Redeam can keep track of them and their data.

Redeam will continue to use the name beta keys until there is a pressing reason for a name change of a key or the fields are added as attributes to the spec. However, we will be notifying our partners who have implemented them well in advance.

Examples of beta keys

  • beta-deliveryMethod
  • beta-availabilityPricingType
  • beta-ticketLocations

Please use all extensions with the beta- prefix, note that the data and keys will vary depending on the partner integration.

If no additional data is communicated in the extensions, the field can be empty or hidden.

Internal Keys

x-(key) Internal keys are keys Redeam use internally when we develop either the Reseller or OBS system and need to pass data along that is for internal use only. These keys will all be prefixed with x- to identify them as internal keys.

During development of a connection to the Reseller or Operator / Ticketing System Redeam use keys labelled x-(key)to internally pass data between the different systems.

Example of x keys

  • x-http202-enabled

Please note that the x-(key) are for Redeam's internal use only and should not be exposed to our partners and we are currently working on achieving this.

Please do not develop the keys with an x- prefix as they will be excluded from distribution!

It is important to note that Redeam already use the x- prefix for internal keys, no Operator or Reseller should ever create an extension starting with x- or it will be excluded from distribution.

Partner Specific Keys

In some integrations Operators and Resellers need to share information that is very specific to them, this data can be shared using (partner).(key). These are the keys created specifically for this partner integration and will not be used in any other integration, therefore Redeam will not add them to their spec which is why the beta keys cannot be used.

Examples of partner keys

  • disney.marketRegions
  • disney.discountGroups
  • ticketmaster.safetix

No Prefix Keys

Any other data the Operator and Reseller want to share under the extensions can be added with any value as a no prefix key. It needs to be discussed between the partners how to handle this data.

Please note that Redeam do not need to keep track of no prefix extensions apart from these:

  • supplier.reference
  • resellerReference
  • redemptionInstructions

If an Operator and Reseller would like to use extensions to pass information we recommend they put their name at the start of the key

Examples of no prefix keys

  • (operatorname)-pickupLocation
  • (operatorname)-pickupTime
  • (operatorname)-pickupId
  • (resellername)-dietryRequirements

Locations for Extensions

Redeam use extensions for some time, they are already available in the Reseller API. The tables below give an overview of the corresponding fields in both the Reseller and the Operator APIs with the links to the specs.

Suppliers

Operator API v2Reseller API v1.2
RESPONSEsupplier.extensions New supplier.extensions Already Existed in Spec

Example

Resellers can see a list of the Disney Suppliers divided by property brands (DWD, DLR…) and Points of Sale under the extensions.

Example
Copy

Products

Operator API v2Reseller API v1.2
RESPONSEproduct.extensions New product.extensions Already Existed in Spec

Examples

Resellers connected to Disney can use the details in the extensions to identify if it is Theme Park, Special Event or Waterpark and the product duration.

Example
Copy

Resellers connected to Operators via Ticketmaster can see the following:

  • beta-availabilityPricingType: informs the Reseller if it is an attraction, seating or best available product
  • beta-localStartDate: this field identifies each date of a multiple date product
  • redemptionInstructions: this field holds information related to the venue and product to be considered by the customer for entry
Example
Copy

Options / Rates

Operator API v2Reseller API v1.2
RESPONSEoption.extensions New rate.extensions Already Existed in Spec

Example

Resellers connected to Disney see Supplier and product information along with rate level details in an accumulative form. The example below shows the buffer days applied to the ticket selected

Example
Copy

Units

Operator API v2Reseller API v1.2
RESPONSEunit.extensions New rates.travellertype.extensions New

Example

Example
Copy

Availability

Operator API v2Reseller API v1.2
RESPONSEavailability.extensions New availabilities.extensions New

Examples

Resellers connected to Operators via Ticketmaster:

  • For any sports game, the host team displays under product name and the host name vs the opponent in the EventName
  • The currentTicketLimit changes dynamically with inventory updates and if at any time a hold is made for a number of travelers higher than the current ticket limit value, it will fail
Example
Copy

Create a New Pending Booking / Acquire a Hold

Operator API v2Reseller API v1.2
REQUESTextensions New hold.ext Already Existed in Spec
REQUESTunitItem.extensions New hold.item.ext Already Existed in Spec
RESPONSEextensions New hold.ext Already Existed in Spec
RESPONSEextensions New hold.ext Already Existed in Spec

Example

When dealing with seating product types, Redeam shares the seat details in the booking response to the Reseller

  • beta-ticketLocations: contain the assigned seat information for the Reseller to share with the buyer
Example
Copy

Confirm an in-progress Booking / Create a Booking

Operator API v2Reseller API v1.2
REQUESTextensions New booking.ext Already Existed in Spec
REQUESTbooking.contact.extensions New booking.customer.extensions New
REQUEST Doesn't exist at this point booking.items.ext Already Existed in Spec
REQUESTbooking.guestDetails.extensions New booking.items.traveller.extensions New
RESPONSEbooking.extensions New booking.ext Already Existed in Spec
RESPONSEbooking.unitItems.extensions New booking.items.ext Already Existed in Spec

Examples

Operators may require additional details for each traveler when a booking is being made, therefore, Redeam added extensions at the item.traveler level to collect the data from the Reseller side (Reseller API v1.2) and map to the guestDetails array on the Operator side (Operator API v2)

  • beta-height: guest height with unit measure
  • beta-weight: guest weight with unit measure
  • beta-hotel: guests's hotel details
  • beta-identifications: guest's official, government issued travel document
    • needs to be in a specific comma-separated key-value pair format
      • type: type of document (e.g. Passport, Military ID, Drivers License, National ID, Vaccination Certificate)
      • value: document number (e.g. Passport number. Military ID number, etc)
Reseller API v1.2
Operator API v2
Copy

When dealing with seating product types, Redeam shares the seat details in the booking response to the Reseller

  • beta-ticketLocations: contain the assigned seat information for the Reseller to share with the buyer

Still in the booking response

  • beta-deliveryMethod: to the Reseller whether this confirmed booking contains one ticket per-unit, (TICKET) or one ticket per-booking (VOUCHER)
  • supplier.reference: maps the Ticketmaster Order Number added once the booking is confirmed. This is required information for the Reseller to pull and add to the voucher.
Example
Copy

Order

Please note that this capability / functionality only exists for the Operators at this time.

Operator API v2Reseller API v1.2
REQUESTorder.extensions New booking.extensions Already Existed in Spec
RESPONSEorder.extensions New booking.extensions Already Existed in Spec

Cancel a Booking

There is no request and response body in the Reseller cancellation transaction.

Operator API v2
REQUESTextensions New
RESPONSEbooking.extensions New
RESPONSEbooking.unitItems.extensions New

SCAP

Please note that this section is only for Resellers using the SCAP Flow (Seat Chart Availability & Pricing) for specific seat selection distribution.

GET Section Availability

v2 SCAP Models
RESPONSEsectionAvailabilities.extensions New
RESPONSEsectionAvailabilities.section.extensions New
RESPONSEsectionAvailabilities.availability.extensions New

GET Section Seats

v2 SCAP Models
RESPONSElocations.extensions New
RESPONSElocations.section.extensions New
RESPONSElocations.row.extensions New
RESPONSElocations.seats.extensions New
Type to search, ESC to discard
Type to search, ESC to discard
Type to search, ESC to discard