Hopper Disruption Guarantee (DG) API

**What is Disruption Guarantee?** Disruption Guarantee (DG) offers a premium disruption assistance service to customers in case of flight disruption, including rebooking options on any airline or a refund option. **** **How it works** There are two distinct flows for DG: - The _purchase flow_, enabling customers to purchase the product within the airline’s booking flow. - The _exercise flow_, enabling customers to benefit from the premium disruption assistance service in case of a flight disruption. For the _purchase flow_, the first step is to [Create a Session](#operation/postSessions) Both the purchase and the exercise of DG should be tracked by the airline in the airline’s Passenger Name Record (PNR) according to the applicable industry standards. **** **Purchase flow** DG follows the industry standard of a two step purchase process. 1. Once the user is landing on the page displaying the DG offer, the airline will call the [Create DG Offers](#operation/postDg_offers) endpoint. DG Offers can be created at multiple granular levels. The request must include a description of the Itinerary for which the offers are requested. The response will contain - the price for the product (`premium`), - the refundable amount (`coverage`), - the maximum price per passenger for a new flight (`service_cap`), - the delay threshold to trigger the policy (`min_minuted_delay`), - the start of the timeframe to trigger the policy (`max_hours_before_departure`) - and the description of the offer in the user’s language (`contents`). 2. If a user is attaching DG to his booking, the airline will call the [Create DG Contract](#operation/postDg_contracts) endpoint. The request must include the selected offer\_id(s) and a description of the Itinerary for which the contract is requested, which must match the one of the Offer. At this stage, the DG Contract is only _created_. It will be confirmed once the customer has made the payment, which can be done in two ways: 1. If the airline is the Merchant of Records (MoR), it will capture the payment for the total amount of the booking, including the DG fee amount. Upon a successful payment, the airline will call the Update DG Contract Status endpoint to set the DG contract to _confirmed_. The airline will track this purchase in its PNR following the industry standards that apply to ticketing or ticketless carriers. 2. If HTS is the Merchant of Records (MoR), the airline will capture the payment for the amount of the booking excluding the DG fee, while HTS will capture the payment for the DG fee amount. Upon a successful payment of its portion, the airline will call the Process DG Payment endpoint for HTS to capture the payment for the DG fee amount. Once successful, the DG contract will be set to _confirmed_. The airline will track this purchase in its PNR. The details of a DG contract can be retrieved at any time through the [Get a DG Contract](#operation/getDg_contractsId) endpoint. **** **Exercise flow** In this version of the API, the DG exercise is powered by HTS as a standalone flow, without any endpoint publicly exposed.\ In a future version of the API, the DG exercise will be initialized from the “Manage My Bookings” (MMB) page of the airline. New endpoints will be released to that purpose.