The Dihedral Event API provides the mechanism for a data provider (you) to publish information about your products, your services, your customers, and all the related travel events that occur with those customers.
Unlike a typical API that you may be accustomed to dealing with, our API consumes and publishes data
in an Event format. Every transaction is considered an event since each message may trigger
actions and behaviors to downstream systems and/or subscribers of the data. Some events may seem be simple
static data updates. For example a HotelInfo event may contain details about a hotel property
and its policies. This is still considered an event since it's addition or update may trigger a subscriber
to respond to that change, or it may trigger processing related to all the travelers that are staying at
the property. The resulting actions taken per event will vary greatly from event to event, but they will
all trigger an action in one form or another.
All requests will be authorized via an HMAC request signing mechanism. This will be identified via the
Authorization header added to the request. Please see the Auth
section for details and examples.
For publishing information, there is only one endpoint for submitting data. The /publish/v1/events
will accept a POST request and will accept one root object, the EventEnvelope.
Besides the authorization header that allows you to be authenticated, there are a few other optional headers that can be added to a request.
allalldiag-onlyThe EventEnvelope is the top level object sent for all requests. It is a simple
container for encapsulating the events that are sent within a request. It also provides the
basis for future enhancement of the API without complex versioning. Future additions can be
added to the envelope to provide context about the events, or other more global request
constructs, without necessarily affecting the list of the events.
From a RAML point of view, the event envelope is defined as:
EventEnvelope:
type: object
properties:
Events:
description: An array of Events
type: Event[]
minItems: 1
The Event is the fundamental object that represents data published to our system.
It is a simplistic structure designed to provide context about the event, as well as a list of
Key/Value pairs that describe the details of the event.
All data within the event will be represented as strings. Those values will be validated according to rules associated with each event. Those rules will specify which fields are required, which are optional, and ensure they are properly formatted. The complete list of events and how they are validated are detailed in the Events section.
From a RAML point of view, the event is defined as:
Event:
type: object
properties:
Type:
type: string
CustomerId:
type: string
ReservationId:
type: string
Timestamp:
type: string
Action:
type: string
Method:
type: string
EventData:
type: any
There are a handful of fields on the event that describe and dictate the type of event that is being published. They are as follows:
| Field | Description | Usage | Icon |
|---|---|---|---|
| Type | The type of event that is being published | Required | |
| Timestamp | The date and time that this event was initiated. It should not be the time that it was transmitted. Specified in UTC. | Required | |
| CustomerId | The ID of the customer as the publishing entity identifies them. | Required for some events | |
| ReservationId | The ID of the reservation as the publishing entity identifies it. | Required for some events | |
| Action | Some events can specify an action to identify the event as something other than new content. For example: delete |
Allowed on some events | |
| Method | Identifies the method in which the event was generated. For example: mobile
|
Optional | |
| EventData | The data that describes this event. | Required on most events |
The event types are grouped into four different categories. The usage and validation of the event can vary greatly by which group the event belongs to.
| Group | Description |
|---|---|
| Customer | An event that defines information about the Customer. |
| GXR | An event that defines the details about a booking and/or reservation. |
| Lookup | An event that contains common information that can be referenced by other GXR events.
These are typically info events about publisher entities. Example: HotelInfo |
| Provider | An event that either stands on it's own and provides information not directly related
to a customer or a GXR, or an event that relates to a group of GXRs, and may effect many
reservations. Example: AirScheduleChange |
| Calculated | A calculated event is not one that is published by a travel provider, but an event
that Dihedral produces that is derived from the contents of other events within the
same reservation. These events are used in Data Bundle configurations just like other
events, and they typically consist of aggregate or summations of values from the other
events. Example: AirBagSummary |
The following responses will be returned on successful requests
200204In the event of an error, we will return a proper HTTP response code as well as a response message that will provide any details about the problem.
400401403429Here is an example of a simple, single event request. More can be found in the Examples section.