close

Sign in

To view secure documentation please login with EAN Service Desk, using the link below.

EAN service desk

No EAN Service Desk account?

Please contact your EAN representative

Login
Sign in
Rapid

NotificationsAll Versions

This page outlines the Notifications Service, which sends you alerts for booking events

Overview

EAN Notifications is a solution that lets you integrate with EAN more closely than ever. When changes occur that can impact your business, EAN will push details of the change directly to your systems via standard POST messages.  With our push notifications, you can remain informed, simplify operations, and scale your business.

We currently support notifications for all booking events that occur outside of our API. So if a call center makes a change or a hotel cancels a booking, you'll be notified immediately. This is just the beginning – more notification event types will be coming soon.

By enabling a seamless integration with your business, these notifications serve to complement the following EAN products and services:

  • EAN Rapid APIs
  • Affiliate Voyager agent booking tool
  • Partner and customer support services

new tools We now offer a Test API for all event types supported for Notifications. See full details in the next major section below. If you do not wish to set up your own requests, you can also use our new Notifications Tester tool.

Supported Message Types

EAN Notifications can inform your systems with a message for the following events:

Source Event Details
Customer support agent or Affiliate Voyager Booking Creation A new booking was created by an EAN customer support agent or Affiliate Voyager.

Booking Update

An existing booking was updated by an EAN customer support agent or Affiliate Voyager.

Booking Cancellation An existing booking was canceled by an EAN customer support agent or Affiliate Voyager.
Hotel Booking Cancellation An existing booking was canceled by the hotel.  The customer should contact your business' customer support.
Expedia

Booking Cancellation

An existing booking was canceled by Expedia because the booking did not comply with the terms and/or conditions applicable to the transaction.

The customer will need to contact transactionprocessing@travelscape.com with their telephone number and the best time to discuss the cancellation.

Message Schema and Details

All messages adhere the schema outlined below. As new message types are added for different events, the schema may vary.

Object Description
event_id Unique identifier for each message
event_type

An indication of what event caused the notification.

This value can be used for message handling and routing.

Refer to the list of event types for more information.

event_time

Timestamp of the event notification, in UTC

itinerary_id

The Itinerary ID of the affected booking

email

The customer e-mail address associated with the affected itinerary

message

Description of event notification

affiliate_reference_id The Affiliate Reference ID of the affected booking

Supported Message Topics

Source Event event_type Value
Customer support agent or Affiliate Voyager Booking Creation itinerary.agent.create
Booking Update itinerary.agent.change
Booking Cancelation itinerary.agent.cancel
Hotel Booking Cancelation itinerary.supplier.cancel
Expedia Booking Cancelation itinerary.fraud.cancel

Each message is an HTTPS POST request with a JSON message body.

Example:

{
     "event_id": "dbacce6c-afcb-4b23-ae66-48050757551c",
     "event_type": "itinerary.agent.create",
     "event_time": "2017-08-09T16:47:32.039Z",
     "itinerary_id": "8091234567890",
     "email": "customer@example.com",
     "message": "An agent created a new itinerary."
     "affiliate_reference_id": "b086d299-2f1f-4134-a23c-f4a1c9286fac"
 }

Integration

Receiving a Message

To start receiving notifications, you will need to stand up a publicly accessible HTTPS endpoint that can accept a POST message that will be pushed to your endpoint.

Work with your EAN Integration Consultant to get set up and provide them with:

  • A list of event topics you want to subscribe to (listed above)
  • The URL for your endpoint to handle messages

We are working to provide you with self-service tools to test your integration. Until then, your Integration Consultant can help you make test bookings to confirm that you're receiving notifications for the offline events you subscribed to.

Important Configuration Notes

  • EAN uses cloud-based servers - ensure your listener endpoints are configured to receive notification pushes from different potential IP addresses.
  • If you wish to change your endpoint URL, you must keep the original URL live until we validate your new URL for receiving notification pushes. Contact your EAN representative before making such changes.
  • Only one URL may be used for notifications – variation on event_type or other criteria is not supported.

 

Handling a Message

When you receive a message that a booking event has occurred, use the itinerary ID and email address from the message to retrieve the latest booking details.

Messages may arrive unordered. Refer to the timestamp to determine ordering and retrieve the itinerary for booking events to obtain the updated status.

After receiving the message, your integration must respond with the appropriate HTTP status code. Any message that does not receive a 200-level status code will be considered undelivered and will be queued for a retry by the notification service.

Handling Result Details Response Status Code

Success

  • The message was received as expected
  • The message was handled properly

200

Failure

  • The message was not received as expected
  • The message could not be handled properly

400s

  • The client could not process the message due to a client server error

500s

Undeliverable Messages

If we are unable to successfully deliver a message to your endpoint, we will automatically retry following the schedule below:

  1. First retry after 5 minutes
  2. Second retry after 1 hour
  3. Subsequent retries every 12 hours for 7 days (14 total)

You may receive a duplicate message if we don't receive a confirmation of receipt (200 OK status code) and the message gets queued for retry. You can identify a duplicate message by locating the same event_id but a later timestamp than the original.


 

Notifications Test API

The EAN Notifications Test API allows you to request test notifications to be sent to your specified test endpoint to verify your integration with the Notifications Service. You can also use our Notifications Service Tester to fire test notifications directly to your endpoint without building your own requests.

Important Notes

This service's request function is not present for the production Notifications API - you cannot send requests to the live endpoint to trigger or refresh production notifications. Requests are offered via this test API for testing purposes only.

Since this API is for test purposes only, its GET request trigger is only available via test.ean.com.

Message Schema and Supported Message Topics

All test notifications adhere to the same schema and the same message topics as a production notification, as outlined in the Notifications API documentation prior to this section.

Integration

Receiving a Message

To start receiving test notifications, you will need to stand up a publicly accessible HTTPS endpoint that can accept a POST message that will be pushed to your endpoint.

Work with your EAN Integration Consultant to get set up and provide them with:

  • A list of event topics you want to subscribe to for testing (listed above in the previous section)
  • The URL for your test endpoint to handle test notifications

If you fail to receive a test notification after 30 minutes of requesting, please reach out to your EAN Integration Consultant to help you resolve your issue.

Important Notes

In the notifications you receive, there will be no distinctions between a test notification and a production notification. We strongly recommend you to set up an endpoint specifically for test notifications to positively isolate test vs. production messages.

By setting up different endpoints for test and production, you will only receive test notifications at your test endpoint, and likewise you will only receive production notifications at your production endpoint.