Customer modifies their reservation
When a customer modifies their reservation such that the price, location, or dates of the reservation change, we require the partner to let us know so we can modify the associated Weather Guarantee.
Changes that don't require a modification
Not all changes to a reservation require a modification to the Weather Guarantee, though it is sometimes simplest to modify the Weather Guarantee for any change. Changes that don't require a modification are:
- Price: when the price of a reservation changes by less than 10%, it is acceptable to reuse the existing Weather Guarantee. For example, if a customer changes room type but the difference in price is 5%, then the existing guarantee can remain.
- Location: when the location of a customer's reservation changes by less than 5km, it is acceptable to reuse the existing Weather Guarantee. For example, if a customer changes their campsite location from one side of the property to another side of the property.
Modifying a Weather Guarantee
There are different modification scenarios, but all of them follow the same general flow.
- The partner will call Modify Guarantee with the Weather Guarantee ID and the required modification
- The API will return a response with a list of proposed modifications and a flag indicating whether the customer must opt in to the change
- The partner will present the modified Weather Guarantee details to the customer in their booking modification UI
- When the customer confirms the change to their booking, the partner will call Confirm modification with the ID returned in step 2 if the modified Weather Guarantee is accepted or if the modification does not require the customer to opt in.
- If the customer declines the change to the Weather Guarantee, the partner will call Decline Guarantee Quote.
Create Modification
Request
The Modify Guarantee endpoint accepts a request body containing the Guarantee ID and fields that indicate which part of the Weather Guarantee needs to be modified. The following fields can be passed in the request to indicate which part of the Guarantee to modify:
coverage_start_date
: Modified booking start date (str, "YYYY-mm-dd" format)coverage_end_date
: Modified booking end date (str, "YYYY-mm-dd" format)exposure_total_coverage_amount
: Modified booking price (float)coverage_start_hour_number
: Modified coverage start hour (int)coverage_end_hour_number
: Modified coverage end hour (int)exposure_name
: Modified exposure name (str)exposure_latitude
: Modified exposure latitude (float)exposure_longitude
: Modified exposure longitude (float)exposure_address
: Modified exposure address (json)
It is possible to pass multiple fields and perform multiple modifications in a single request.
Response
All calls to Modify Guarantee will return the same response body, but certain modifications will need to be handled differently. There are two types of modifications: one type requires the customer to explicitly accept the change and the other type does not.
Customer Opt-In not Required
The following scenarios don't require the customer to accept the change:
- The
exposure_total_coverage_amount
decreases which causes the cost of the Weather Guarantee to decrease proportionally coverage_end_date
is decreased orcoverage_start_date
is increased, causing the reservation to decrease in length within the original booking dates. For example, the original trip was October 20 to October 25, but the end date is changed to October 23 or the start date is changed to October 21. This will be accompanied by a decrease in theexposure_total_coverage_amount
which will cause the price of the Guarantee to decrease proportionally.
In both cases, we decrease the cost of the Weather Guarantee proportionally with the decrease in the exposure_total_coverage_amount
. If exposure_total_coverage_amount
decreases by 25%, then the cost of the Weather Guarantee will also decrease by 25%.
The response body will look like the following when customer opt-in is not required:
{
"modification_quote": {
// quote body
},
"id": "497034f2-7cc6-46b4-8fbb-5f7ba8fbc1fc",
"price_change": -3,
"risk_rescored": false,
"risk_rescored_reason": "",
"user_opt_in_required": false,
"reference_guarantee_id": "2f524226-d905-4950-a00e-4a01fd0533bb",
"plain_language": {
"coverage_changes": "Your weather guarantee was re-assessed and your coverage details may have changed."
}
}
The partner should display the coverage_changes
plain language to the customer in their booking modification UI, but the customer does not need to opt in again, which is reflected in user_opt_in_required
being set to false.
Customer Opt-In Required
All other modification scenario requires the customer to opt-in to the new Weather Guarantee. These scenarios are:
- The length of the trip increases, which can occur by the
coverage_start_date
moving up in time, thecoverage_end_date
moving back in time, or a combination of both. For example, the original trips dates are January 5 to January 10 and thecoverage_end_date
is changed to January 13. - The dates of the trip change such that none of the new dates overlap with the previous dates. For example, the original trip was February 3 to February 5 and the new dates are February 22 to February 24.
- The
exposure_total_coverage_amount
increases which means the customer will be charged for the difference in cost between their existing Weather Guarantee and the new Weather Guarantee. - The location of the exposure changes. This is represented by a new
exposure_address
or a new combination ofexposure_latitude
andexposure_longitude
. For example, a customer changes their tee time to another course that is 20 miles away.
In these cases, the price of the new Guarantee will change to reflect the new risk profile of the booking. This means the price may increase or decrease and the deductible hours may change. The response will look like the below
{
"modification_quote": {
// quote body
},
"id": "497034f2-7cc6-46b4-8fbb-5f7ba8fbc1fc",
"price_change": -3,
"risk_rescored": true,
"risk_rescored_reason": "location modification outside of threshold",
"user_opt_in_required": true,
"reference_guarantee_id": "2f524226-d905-4950-a00e-4a01fd0533bb",
"plain_language": {
"coverage_changes": "Your weather guarantee was re-assessed and your coverage details may have changed."
}
}
user_opt_in_required
is now true, which means the customer must be presented the new Guarantee details and be given the opportunity to decline the new coverage.
Confirm Modification
Every modification should conclude with a confirmation or decline of the change. If the customer opts in to the change, or the change doesn't require an opt-in, then the partner will use the Confirm modification endpoint with the id
returned in the Modify Guarantee response. The endpoint has an optional request body used to pass us the reservation ID if it has changed due to the modification:
{
"reservation_id": "ABC123"
}
The response will contain the modified Weather Guarantee details:
{
"id": "00000000-0000-0000-0000-000000000000",
"product_id": "00000000-0000-0000-0000-000000000000",
"offer_key": "",
"created_at": "0001-01-01T00:00:00Z",
"coverage_start_date": "",
"coverage_end_date": "",
"coverage_start_hour": "",
"coverage_end_hour": "",
"lang_locale": "und",
"wholesale_price": 0,
"suggested_price": 0,
"tax_amount": 0,
"tax_rate": 0,
"tax_was_assessed": false,
"expires_at": "0001-01-01T00:00:00Z",
"currency": "XXX",
"exposure_name": "",
"exposure_latitude": 0,
"exposure_longitude": 0,
"exposure_total_coverage_amount": 0,
"exposure_protections": null,
"payout_tiers": null
}
If the customer declines the modified Weather Guarantee, then the partner will call Decline Guarantee Quote with the id
returned in Modify Guarantee.
Updated 26 days ago