How to publish travel content on the marketplace?
This section describes how to publish travel content on the marketplace.
Travel content can be published directly by travel suppliers, by technology providers on behalf of suppliers, by travel content aggregators or by travel agencies.
Travel content and inventory is not stored on the blockchain, instead travel suppliers publish a public API endpoint from which authenticated travel buyers can search for offers and create bookings.
Prequisites:
- Register your organization in Winding Tree marketplace
- Register your banking details in Simard to receive payouts
Accomodation providers
Accomodation providers should expose the following services from Winding Tree OpenAPI specification:
Mandatory Implementation:
POST /offers/search
: Request offers (Availability, Rates and Inventory)POST /orders/createWithOffer
: Create a booking from an offer
Optional Implementation:
GET /offers/{offerId}
: Retrieve an offerDELETE /offers/{offerId}
: Delete an offerGET /orders/{orderId}
: Retrieve a bookingDELETE /orders/{orderId}
: Cancel a bookingPATCH /orders/{orderId}
: Modify a booking
Flow Overview
The below diagram describes the overall flow for an accommodation booking:
Offers
Offer Request
API: POST /offers/search
For the details of the offer creation to comply with, see the Open API schema
A search request from providers contains two main sections:
accomodation
: The details of the accomodation criteriapassengers
: The details of the guests
An accomodation
object is composed of the following keys:
location
: Contains a GPS coordinate rectangle, circle or polygon.arrival
: The desired check-in date and timedeparture
: The desired check-out date and time
A passengers
object is an array of passenger, which contains:
type
: The type of passengers (example: ADT, CHD)count
: The passenger count for this passenger types
It is also possible to provide the passenger details directly from the search if the details are known at this stage, and the accomodation provider can use them to provide personalized offers.
Processing an offer Request
The below diagram describes the logic an accommodation provider should implement:
Business function | Technical Considerations |
---|---|
Retrieve Buyer ORGiD Details | Achieved by verifying the provided authentication token and resolving the associated organization. |
Buyer acceptance | Using the details of the organization, the travel supplier can check internal business rules (identifier, country, trust level, rate limits, ..) to determine if such buyer is allowed to transact. |
Accomodations Match | Using the geographic coordinates of the area provided in the request, the travel supplier determines if there is any matching accommodations in its portefolio. |
Retrieve availability and rates | The travel supplier retrieves from its internal system (PMS, CRS, CM, ..) the rates and availability to offer. In case of negotiated rates, the supplier can retrieve the proper rates using the organization details. |
Create Offers | The offers should be stored for further reference during the booking step and ensure consistency. It is recommended to implement an efficient caching mechanism and store the offers for at least 30 minutes, for example using Redis or Memcached. |