Data Planning
Hahn Air will pass consumer data via webhooks to allow us to send communications and personalize landing experience.
Events
We generally set up three endpoints for each partner for the following events:
Event | Use | Importance |
|---|---|---|
Booking Create | When the consumer creates a new booking | Scheduling marketing and personalising UX |
Booking Update | When the consumer updates any information on an existing booking | Ensure we do not personalise experience based on stale data |
Booking Cancel | When the consumer cancels a booking | Ensure that we do not send any marketing when trip has been cancelled |
Send a Post Request with booking data in any json format to webhook
Multi-Destinations
When a trip is a multi-destination trip (2 or more days in 2 or more destinations in a single trip) then each segment will need to be passed as a separate booking with a separate external reference (consumerTripPartnerExternalReference) which can be aggregated under one booking.
Example:
Trip Example: 3 nights in San Francisco, 3 nights in Los Angeles and 3 nights in Las Vegas with Booking reference 1234
External references to be passed:
3 nights in San Francisco =
consumerTripPartnerExternalReference1234-13 nights in Los Angeles =
consumerTripPartnerExternalReference1234-23 nights in Las Vegas =
consumerTripPartnerExternalReference1234-3
@a user to tag Hahn Air:
- @a user (Hahn air) to confirm if they have booking amend and booking cancel
- @a user to create 2 tickets for the beginning of next sprint:
To create webhooks for Hahnair
For data ingestion of Hahnair.
Authentication
We do not require any authentication on our endpoints, making them extremely easy to integrate with. They are protected by “security through obscurity”. If the endpoint itself is treated as a secret then it is safe.
Data Points
Data Point | Use | Field Name | Format | Required | Example |
Trip start | Message is triggered based on this date and time. This will be start time of outbound flight |
| Formatted as strings in ISO-8601. Time needs to be UTC | Yes | 2024-02-09T08:21:41Z |
Trip end | This should be be the start time of return flight if trip has a return leg. |
| Formatted as strings in ISO-8601. Time needs to be UTC | No | 2024-02-09T08:21:41Z |
Booking date | This is the date & time that the booking was made. Allows ability to configure send time or content based on booking window |
| Formatted as strings in ISO-8601. Time needs to be UTC | Yes | 2024-02-09T08:21:41Z |
Departure Airport code | This will be the airport their trip is beginning from |
| Yes | ||
Destination Airport code | This will be final destination they are heading to |
| Yes | ||
Depature Name | This will be the depature destination City name (eg. London, Dublin etc) |
| No | ||
Destination Name | This will be the final destination City name (eg. London, Dublin etc) |
| Yes | ||
Customers Departure Country | We only want to target specific countries |
| No | ||
Customers Destination Country | We only want to target specific countries |
| No | ||
Customer Unique ID | Will use to identify customer in case of changes |
| Yes | ||
Customers phone number | To send WhatsApp message |
| Format in E.164 | Yes | |
Customer Name | To personalize message |
| First name only | No | |
Booking id | This will be used in site URLs to have personalized site & to manage amends and cancellations |
| Yes | ||
Bag Count | Used to personalize recommendations |
| number | No | |
Pax | We can use the number of people in booking to personalise message |
| number | No | |
Children | We can personalise message if we know there are children in the booking |
| number | No | |
Infant | We can personalise message if we know there are infants in the booking |
| number | No | |
Flight Class | We can personalise message if we know the travel class |
| No | ||
Departure Flight Number | To personalize message |
| Two-character airline designator and a 1 to 4 digit number | No | |
Customers email address | To send email |
| Yes |