About

Norwegian Shop and Order API is based on NDC (New Distribution Capability). NDC is a travel industry-supported program (NDC Program) launched by IATA for the development and market adoption of a new, XML-based data transmission standard (NDC Standard).

Versions

You must explicitly request the 17.2 version via the Accept header.

Media Types

Custom media types are used in the API to let consumers choose the format of the data they wish to receive. This is done by adding one or more of the following types to the Accept header when you make a request. Media types are specific to resources, allowing them to change independently and support formats that other resources don’t.

All Norwegian NDC media types look like this:

application/vnd.nas.ndc[.version].param[+xml]

The most basic media types the API supports are:

application/vnd.nas.ndc.v17.2+xml
Important
 the default version of the API may change in the future. If you’re building an application and care about the stability of the API, be sure to request a specific version in the Accept header as shown in the examples below.

You can specify a version like so:

application/vnd.nas.ndc.v17.2+xml

General information

Sender and participants

This identifies you as a party.

Online Travel Agency

Online Travel Agencies should at least fill out the following information in all NDC requests:

<Party>
    <Sender>
        <TravelAgencySender>
            <Name>Zeus Travel</Name>
            <AgencyID>AgencyID provided Norwegian</AgencyID>
        </TravelAgencySender>
    </Sender>
</Party>

The AgencyID you are provided by Norwegian should be entered in the AgencyID field. The sale is registered on the provided AgencyID.

Important
 If the agencyID can not be found the sale is registered on the user of the API.

Bookings will be available from Norwegian Agent portal.

Note
 An AgencyID starts with DYAPI. Example DYAPIZEUSTRAVEL.

Aggregator / Distributor

If you act as an aggregator/distributor you should at least fill out the following information in all NDC requests:

<Party>
    <Sender>
        <TravelAgencySender>
            <Name>Name of travel agency</Name>
            <AgencyID>AgencyID provided Norwegian</AgencyID>
        </TravelAgencySender>
    </Sender>
    <!-- Important if you are an aggregator/distributor-->
    <Participants>
        <Participant>
            <AggregatorParticipant SequenceNumber="1">
                <Name>JR TECHNOLOGIES</Name>
                <AggregatorID>Aggregator AgencyID provided by Norwegian</AggregatorID>
            </AggregatorParticipant>
        </Participant>
    </Participants>
</Party>

Sender is the original sender of the message. Participants should be filled out with your data as aggregator/distributor.

In this example JR TECHNOLOGIES is selling tickets on behalf of the travel agency.

Note
 A sequence number of 1 indicates that this is the first Participant involved in the transaction.

General data for all NDC APIs

Name Description Format

Target

Used to indicate whether the request is for the Test or Production system

Valid values: Test or Production

Version

For all IATA versioned messages, the version of the message is indicated by a decimal value

17.2

TimeStamp

Message creation timestamp

ISO 8601 format YYYY-MM-DDTHH:MM:SSZ

CorrelationID

Allow end-to-end correlation of log messages

A string of length 1 to 64

TransactionIdentifier

Identifier to relate all messages within a transaction (e.g. this would be sent in all request and response messages that are part of an on-going transaction)

A string of length 1 to 32

Passenger name validation

Supported characters

A subset of Latin Unicode characters are supported (Basic Latin and Latin-1 Supplement).

Note
 Names in GDS are stored with Basic Latin, so if customer use Latin-1 Supplement characters, they will be converted to Basic Latin. Some of these characters will then be converted to two characters (e.g. æ,ø,å). This has an impact on "Name length restrictions" (see section below)
Passenger name RegExp

^[A-Za-z ÁáÀàÂâÄäÃãÅåÇçÐÐÉÈÊËéèêëiÍíÌÎÏïñÑØøÓÒÔÖÕóòôõöŠšÚÙÛÜúùûüŽžÝýŸÞÆæþŒœß-]*$

See more details here: https://en.wikipedia.org/wiki/List_of_Unicode_characters

Name length restrictions

  • Last name can minimum be 2 characters and maximum 30 characters

  • First name can minimum be 2 characters and maximum 30 characters

  • Total length of first name and last name is maximum 48 characters

    • NB: When an adult travels with an infant, total length of both adult and infant is 41 characters

  • NB: Passenger title and type are inculcated in passenger name, but has been counted for in rules above, as long as title is only 2 characters (e.g. MS, MR)

  • Two or more passengers on a booking cannot have identical names

  • First name and last name of a passenger cannot be identical

E-mail address validation

  • Maximum length is 47 characters

  • Minimum length is 6 characters

  • Must contain character @

E-mail RegExp

^([a-zA-Z0-9_\-]+\.)*[a-zA-Z0-9_\-]+@((([a-zA-Z0-9]{1}[a-zA-Z0-9\-]{0,62}[a-zA-Z0-9]{1})|[a-zA-Z0-9])\.)+[a-zA-Z]{2,6}$

Client Errors

Client errors on API calls that receive request bodies will result in a 422 Unprocessable Entity response:

HTTP Response
[show]

API overview

API Description

AirShopping

Returns flight product prices for requested origin, destination and date. Provides the cheapest available offer.

ServiceList

Returns a list of applicable ancillary services that meet request qualifiers and flights.

SeatAvailability

Returns data used to construct respective seat maps with fully integrated fees for any identified premium seats.

OfferPrice

Returns final pricing. If ancillary services are available, the modified pricing request includes selected services and returns a final pricing that includes service(s) selection.

Payment

Information about payment.

OrderCreate

Creates a booking and issues tickets for the supplied itinerary and passenger details, returning a booking reference.

OrderRetrieve

Retrieves an order.

OrderCancel

Cancels an order.

API flow

The diagram below shows how the different APIs can be used.

API flow
Note
 ServiceList and SeatAvailability are optional requests.

Scenarios

Scenarios to demonstrate how the APIs are used.

API Description

Scenario 1

LowFare, one-way for one adult with one bag

Scenario 2

LowFarePlus, one-way for one adult. Change meal to vegan.

Glossary

ShoppingResponseID

Unique shopping session response ID. Used as reference when requesting an order to be created. See Order Create API.

OfferId

Globally unique Offer instance ID. Used as reference when requesting an order to be created. See Order Create API.

OfferItemId

Globally unique OfferItem instance ID. Used as reference when requesting an order to be created. See Order Create API.

References

Other resources