API Development Guide


Introduction

This companion guide to the RightRez API Documentation provides additional details and usage patterns about many of the more common API methods.

Basic Flight Availability and Booking API Usage Pattern

The following instructions should assist a developer in getting basic availability and booking functionality up and running as rapidly as possible. If a quickstart sample exists for your preferred development platform, you should be able to follow along and cross reference what this document is describing with what the quickstart sample code is doing.

Authentication

Nearly all of the API methods require authentication, and many require additional permissions. Therefore, the first task of any interaction with the API is to request an authentication token by posting credentials to the authentication token service, located at

POST https://softapi.rightrez.com/api/Token

for this API server. This call returns a token which must be set on the request headers of subsequent API calls, or the server will response with a 401 Unauthorized status code.

Availability

Once the token has been procured, the next step is to construct and issue an availability request to the flight availability method.

POST https://softapi.rightrez.com/api/FlightAvailability

There are a large number of options and parameters which can be set on the request, but below you'll find an example that contains the minimum information required to receive any results:

{
  "ClientId":"FAKE",
  "TripComponents":[
  {
    "DepartCity":"JFK",
    "ArriveCity":"LHR",
    "AirDate":"14Apr14",
    "TripDirection":"OUTBOUND_TRIP",
  },
  {
    "DepartCity":"LHR",
    "ArriveCity":"JFK",
    "AirDate":"21Apr14",
    "TripDirection":"RETURN_TRIP",
  }],
  "Options":
  {
    "BookingType":"AirSea",
  }
}

just change the values for 'ClientId' and 'BookingType' to be appropriate for your setup, and adjust the dates and cities to the request to be issued. This call returns a response that has a property 'AvailableFlights' that is a list of available options and detailed information about them, any of which can be used to construct a booking request. A sample response can be seen at the API documentation page for this method.

Availability Cache
These results (and the original request) are also stored in a temporary cache, which allows for additional operations such as getting more results for a carrier or containing a specific flight, fetching the original request and results, and pricing returned results at a different service level.

Booking

When ready to book a flight, the best course of action is to take one of the options returned by the availability API and construct a booking request to post to the flight booking method.

POST https://softapi.rightrez.com/api/FlightBooking

with it and the 'RequestId' value and adding a list of 'Passengers'. A booking request (with the Flight omitted for brevity) might look as follows:

{
  "ClientId": "FAKE",
  "RequestId": "83d104ff-a0a0-4f3a-8a2c-605eeb172db2",
  "Passengers": [
    {
      "FirstName": "John",
      "LastName": "Fakington",
      "MiddleName": "R",
      "Title": "",
      "Gender": "M",
      "DoB": "07Jul77",
      "PassportNumber": "123456789",
      "PassportExpiryDate": "09Mar17",
      "PassportIssuingCountry": "USA",
      "SeatPreference": "None",
      "BookingNumber": "",
      "BookingSequence": "",
      "Nationality": "US",
      "MealRequest": "AVML",
      "Wheelchair": false,
      "KnownTravelerNumber": "",
      "Email": "fake@nota.real.address",
      "FrequentFlyerNumbers": [],
      "CustomContent": null,
      "PhoneNumber": ""
    }
  ],
  "Flight": {
    ...
  }
}

This will create a booking in the computer reservation system and return a representation of the Passenger Name Record (PNR) and the PNR locator along with additional details about the booking.

Other Availability Operations

In addition to fetching availability through the call described above, a number of other operations can be performed for a period of time after issuing the original request.

Get Cached Results

As mentioned above, availability results are stored in our availability cache for a period of time (default 30 minutes) before they expire. By using the 'RequestId' value returned from the response, an HTTP GET operation can be issued to

GET https://softapi.rightrez.com/api/FlightAvailability/{requestId}

Which will return the original response to the request, and the original request object issued on this response. See the API documentation for complete details.

'Get More for Carrier' and 'Mix and Match'

The availability cache also stores options that were not returned in the original results, which can be retrieved from

POST https://softapi.rightrez.com/api/FlightAvailability/More

in two manners. The first is to get more options for a carrier that was returned in the original results. This is achieved by posting a request with the original availability request's 'RequestId' value and the 2 letter carrier code of the desired carrier for the 'AdditionalId' value to the API.

{
  "ClientId": "FAKE",
  "RequestId": "d2fa5619-1aea-4500-b6d1-22d0390a9ca8",
  "AdditionalId": "DL"
}

The alternative mode for get more is to retrieve more options that contain a specific flight, which we have dubbed 'mix and match', is achieved by forming a request with the original 'RequestId' from the response, and using the 'UniqueId' value from the flight we wish to see results with, which may look something like the following:

{
  "ClientId": "FAKE",
  "RequestId": "d2fa5619-1aea-4500-b6d1-22d0390a9ca8",
  "AdditionalId": "ea499e8a-b80b-486a-8843-f7b728a70b0e"
}

Regardless of the type of 'get more' operation, the additional options are returned on the response in the property 'AdditionalFlights'. A sample response and more details can be found in the API documentation.

'Price Upsell Option' and 'Price Published Option'

POST https://softapi.rightrez.com/api/FlightAvailability/PriceUpsell

The 'PriceUpsell' API method allows any option returned from availability to be priced either in another cabin, or as a published fare, depending on how the request is constructed. An upsell request for a different service level is constructed using the 'RequestId' of the original availability response, the 'TupleId' of the flight we wish to reprice, and the service level character for the desired cabin ("Y" for economy, "P" for premium, "J" for business, "F" for first). Such a request might look as follows:

{
  "ClientId": "FAKE",
  "RequestId": "941c4c82-d061-436a-88da-3ea84d8ad19a",
  "TupleId": "3873e64f-1332-4a15-8ee1-03ce2a1cad23",
  "ServiceLevel": "P",
  "PublishedOnly": false
}

Alternatively, to price as published, set the 'PublishedOnly' flag to true and the result will be returned as a published fare for the service level specified.

See the API documentation for complete details.