Amadeus GDS Integration: SOAP APIs, Authentication and a Real Implementation Plan

01

Amadeus Web Services (SOAP) vs Amadeus Self-Service (REST)

Amadeus publishes two completely separate product lines. Amadeus Web Services — the enterprise SOAP platform, sometimes called WSAP or the Amadeus Travel Platform — is what a licensed travel agency runs in production. It exposes the full GDS: live airline availability, published and negotiated fares, PNR building, automated ticketing, EMDs and queues. It speaks SOAP 1.1 over HTTPS, requires a commercial contract with Amadeus and an office ID, and must pass a certification cycle before you touch production. Amadeus for Developers (Self-Service) is the opposite: REST, JSON, OAuth2, self-signup and a free test tier. It is excellent for prototypes, fare-shopping widgets and MVPs, but its flight content and booking depth are narrower than the full agency platform.

• Amadeus Web Services (SOAP): full GDS content, ticketing, EMD and queues; needs an Amadeus contract, an office ID and certification.
• Amadeus Self-Service (REST/JSON): OAuth2, self-signup, free test tier; ideal for prototypes and search widgets, limited booking depth.
• Both can coexist: teams often prototype on Self-Service, then build the production agency platform on Web Services once the Amadeus contract is signed.
• Your choice is driven by whether you need production ticketing and negotiated fares (Web Services) or fast, low-commitment search and simple orders (Self-Service).

02

Authentication: WS-Security, the security token and session flow

Amadeus Web Services authenticates with a WS-Security SOAP header rather than an API key in a URL. Each request carries a UsernameToken containing the agent login, the office ID, a one-time nonce, a Created timestamp and a PasswordDigest. The digest is not your password in clear text: it is a Base64-encoded SHA-1 hash of the decoded nonce concatenated with the timestamp and the SHA-1 of your password. Because the nonce and timestamp change on every call, the digest changes too, which blocks replay attacks. Amadeus validates the digest against your stored credentials and, for session-based flows, returns a security token and session identifiers you echo back on later calls. Getting the digest algorithm exactly right — decode the nonce before hashing, use the correct concatenation order, keep the timestamp within the allowed clock skew — is the single most common reason a first Amadeus integration fails to authenticate.

03

The booking message flow, named correctly

A flight sale on Amadeus Web Services is not one call; it is a choreographed sequence of named messages, each returning context the next one needs. You do not need to memorise the XML, but you must understand the order, because skipping or reordering a step produces faults that are hard to read. Search is stateless and cheap; from the moment you sell a recommendation you are in a stateful session that must run to ticketing or be cancelled cleanly. Below is the canonical happy path for a published-fare booking. Negotiated fares, EMDs and ancillaries add messages but follow the same spine.

1. 1Fare_MasterPricerTravelBoardSearch — shop live availability and priced recommendations for the journey; stateless, cacheable, the highest-volume call.
2. 2Air_SellFromRecommendation — sell the chosen recommendation, confirming seats are still available and opening the booking context.
3. 3PNR_AddMultiElements — build the PNR: passenger names, contact, ticketing arrangement and any remarks; creates or updates the record.
4. 4Fare_PricePNRWithBookingClass — price the itinerary held in the PNR and create a TST (Transitional Stored Ticket) holding the fare.
5. 5Ticket_CreateTSTFromPricing — confirm the TST from the pricing result so the fare is ready to issue.
6. 6DocIssuance_IssueTicket — issue the e-ticket against the TST, returning the ticket numbers; the session can then be ended.
7. 7PNR_Retrieve — re-read the completed record for confirmation, storage and the customer itinerary.

04

What the SOAP envelope actually looks like

Every Amadeus Web Services call is a SOAP envelope: an outer Envelope wrapping a Header and a Body. The Header carries the WS-Security credentials, the message addressing (the WS-Addressing Action and To fields) and, for stateful flows, the Session element. The Body carries the actual message — the MasterPricer request, the PNR elements, and so on — against an Amadeus-published XSD schema for that message version. You will spend more time on schema versions than you expect: Amadeus pins each message to a version string, and the server rejects a request whose declared version does not match what your office is provisioned for. Build against the WSDL and XSDs Amadeus issues for your contract rather than copying samples from the web, which are frequently a version or two behind.

• Envelope to Header (WS-Security, WS-Addressing action, Session) to Body (the versioned message).
• Each message is pinned to a schema version; a mismatch is rejected before any business logic runs.
• Generate strongly-typed clients from the official WSDL and XSD rather than hand-building XML.
• The WS-Addressing Action tells Amadeus which operation you are calling; getting it wrong returns a routing fault, not a business error.

05

Session management and the stateful-stateless trade-off

The hardest operational problem in an Amadeus integration is session lifecycle. A stateful session holds a live booking context on the Amadeus side, which is exactly what you need to build and ticket a PNR — and exactly what hurts you under load, because sessions are a finite, contracted resource and idle ones time out. A practical architecture keeps search stateless and short-lived, then opens a stateful session only for the sell-to-ticket window, holds it for seconds rather than minutes, and always closes it (TransactionStatusCode 'End' or an explicit sign-out) even on the error path. Treat an abandoned session as a resource leak: monitor open sessions, cap concurrency to your contracted limit and reap anything idle past the timeout.

• Keep search stateless; open a stateful session only for the sell-to-ticket window.
• Always close sessions on both the success and the error path to avoid leaking a contracted resource.
• Cap concurrent sessions to your Amadeus limit and queue beyond it rather than failing.
• Monitor session count and age; alert before you hit the ceiling, not after.

06

Error handling, retries and idempotency

Amadeus faults come in two flavours: SOAP faults (malformed request, auth failure, schema or version mismatch) and application errors returned inside an otherwise valid response (no availability, fare no longer valid, segment sold out). Your code must inspect both. Retries need care: a stateless search can be retried freely, but a booking or ticketing call must never be blindly retried, because a timeout may mean the PNR was actually created and you would double-book. Make write operations idempotent where you can — reconcile by retrieving the PNR before retrying — and treat ambiguous timeouts as verify-then-act, not retry. Map the common error codes to clear user messages: a 'fare no longer available, please re-search' converts far better than a raw Amadeus fault string.

• Distinguish SOAP transport faults from in-response application errors; handle each separately.
• Retry stateless search freely; never blind-retry Sell, PNR build or ticketing.
• On an ambiguous timeout, retrieve the PNR to confirm state before any corrective action.
• Translate Amadeus error codes into actionable user messages; log the raw fault for support.
• Respect Amadeus throughput limits; back off on rate-related faults instead of hammering.

07

Caching search results to control per-transaction cost

Amadeus bills shopping transactions, and a busy OTA fires far more searches than bookings — ratios of 200:1 or worse are normal. Uncached, every re-search, back-button and price-refresh hits Amadeus and your bill. A disciplined caching layer in front of MasterPricer is therefore both a performance and a cost control. Cache priced recommendations keyed by origin, destination, dates, cabin and passenger mix, with a short time-to-live measured in minutes, because fares and availability move. Serve the cache for repeat and near-identical searches, but always revalidate the exact itinerary at the moment of sell — never book a cached fare without a fresh Sell confirming availability and price. The art is choosing a TTL long enough to cut cost and latency but short enough that you rarely show a fare that has already moved.

• Cache MasterPricer results keyed by route, dates, cabin and passenger mix with a short TTL (minutes).
• Always revalidate the chosen fare with a live Sell before building the PNR; never book straight from cache.
• A well-tuned cache cuts both search latency and Amadeus shopping spend, often dramatically.
• Track your look-to-book ratio; it is the metric that tells you whether the cache is doing its job.

08

Test and production environments, certification and onboarding

Amadeus Web Services runs in a test environment first. Your agency signs a commercial contract with Amadeus, receives a test office ID and credentials, and you build and certify against test before production credentials are issued. Certification is a structured run-through: Amadeus, or your local Amadeus organisation, checks that your application builds valid PNRs, prices and issues tickets correctly, handles queues and respects usage rules, before switching you to production. To be explicit about roles: the travel agency or airline holds the Amadeus contract, the office ID and the credentials. Software Chamber is not an Amadeus partner and holds no Amadeus certifications of its own; we implement your application against your Amadeus credentials and run the certification process with you. Certification duration depends on scope and on the Amadeus onboarding queue in your market — plan for several weeks in parallel with development rather than a fixed date.

• You build and certify in the Amadeus test environment before production keys are released.
• Certification verifies correct PNR building, pricing, ticketing and queue handling for your scope.
• The agency or airline holds the Amadeus contract, office ID and credentials — not the development vendor.
• Software Chamber implements against your credentials and runs certification with you; we claim no Amadeus partnership or certification of our own.
• Treat certification as a parallel workstream of several weeks, not a one-day sign-off.

09

A realistic Amadeus implementation plan, timeline and cost

A production Amadeus integration inside an owned OTA is a single-GDS build: Software Chamber delivers it for a fixed $18,000-28,000 over 12-16 weeks, with certification running in parallel. The number moves with scope — search-only is far lighter than full sell-to-ticket with EMDs, refunds and queues — and with how ready your Amadeus contract and office ID are when we start. We deploy to your own cloud account, hand over the source and include three months of free maintenance; we never rent the platform and there is no per-booking fee from us. The schedule below is the shape we actually run. If you only need Self-Service search in an existing site, it is a smaller engagement; if you need multi-GDS, it moves into the $28,000-45,000 range covered in our GDS comparison guide.