In airline distribution, showing a price is easy.

Guaranteeing that price is sellable is where real engineering begins.

Between search and booking, inventory shifts, fare bases expire, ancillaries change, and payment restrictions apply. For Online Travel Agencies (OTAs), protecting revenue and preventing booking failures requires more than just displaying flight options — it requires real-time validation.

The Flight Offers Pricing API (/v1/shopping/flight-offers/pricing) inside the Amadeus Quick Connect API is the commercial safeguard of the booking journey.

For CTOs and engineers building a Flight booking API for OTA platforms, this endpoint transforms an indicative flight offer into a validated, bookable transaction.

If Search is the digital storefront, Pricing is the financial checkpoint.

In essence, this Amadeus flight booking API ensures that a selected flight offer is still available and correctly priced before booking.

It enables your platform to:

• Real-Time Revalidation
  Confirm that the fare is still sellable at the selected price.
• Accurate Fare Recalculation
  Recompute base fare, taxes, and airline-imposed surcharges.
• Ancillary Validation
  Validate paid baggage and paid seat selections.
• Payment-Based Pricing
  Apply card-brand restrictions and credit card fees where applicable.
• Booking Requirements Enforcement
  Return mandatory passenger data requirements (DOB, documents, residence, etc.).

Unlike Search, which provides indicative pricing, the Pricing API provides the final commercial truth before booking.

Within an Amadeus AQC API integration, the Flight Offers Pricing API establishes transactional integrity.

It determines:

• Availability Confirmation
  Whether seats are still open in the selected booking class.
• Fare Basis Accuracy
  Whether the fare basis has changed since search.
• Ancillary Eligibility
  Whether selected bags or seats are still available.
• Payment Compliance
  Whether the airline accepts the provided card brand.
• Ticketing Conditions
  Updated ticketing deadlines and instant-ticketing requirements.
• Because the API is stateless and offer-based, every pricing request recalculates the offer directly against live airline inventory via GDS API integration.

Search informs the user.
Pricing protects the agency.

The integration follows a clean and controlled validation path:

1. Flight Selection
User selects an offer from Flight Offers Search.

2. Authentication
Backend uses Amadeus OAuth2 authentication.

3. Pricing Call
Backend sends the complete flight-offer object to:

POST /v1/shopping/flight-offers/pricing

4. Recalculation
Amadeus:

• Revalidates availability
• Recalculates total price
• Applies ancillaries
• Applies payment fees

5. Validation Output
The updated offer becomes the authoritative input for booking.

Critical rule:

Never reconstruct the flight-offer manually.
Always reuse the exact JSON returned from Search.

Amadeus AQC – Flight Offers Pricing API

Copy
1POST /v1/shopping/flight-offers/pricing

1. Call Flight Offers Search and Persist the Full Offer

Before calling the Pricing API, your backend must:

• Call Flight Offers Search
• Store the complete flight-offer JSON
• Persist it exactly as returned

Critical Integrity Rules:

Do NOT:

• Remove fields
• Recalculate totals
• Modify fareDetailsBySegment
• Change itinerary structure
• Reorder travelers
• Alter booking classes

The search response becomes the base commercial object.

Most OTA pricing failures happen because developers partially rebuild the offer.

2. Allow User to Select Ancillaries (If Applicable)

If the traveler selects:

• Paid checked baggage
• Chargeable seat
• Fare options

You must enrich the offer using the additionalServices field under the correct travelerPricing.

Example – Add Checked Bag

Inside travelerPricings:

additionalServices

• chargeableCheckedBags
• • quantity: 1

Example – Add Seat

additionalServices

• chargeableSeatNumber: 8A

Modification Rules:

You may modify ONLY:

• additionalServices
• payments

You must NOT modify:

• segments
• fare basis
• booking class
• pricingOptions
• traveler mapping

Ancillaries must always be attached to the correct traveler.

3. Add Payment Context (Recommended)

If your OTA supports:

• Credit card-based pricing
• LCC carriers
• Card brand restrictions

Include a payments object with:

• brand (e.g., VISA)
• flightOfferIds

This enables:

• Card-brand validation
• Airline surcharge calculation
• Payment compliance validation

Skipping this step may result in booking rejection later.

4. Authenticate Using OAuth2

Before calling Pricing:

• Generate access token
• Cache the token
• Include header: Authorization: Bearer access_token

Handle:

• Token expiry
• Automatic refresh logic
• Test vs Production environment consistency

OAuth2 authentication is mandatory for every API call.

5. Send the Pricing Request

Endpoint:

Copy
1POST /v1/shopping/flight-offers/pricing

Request must include:

• Complete flight-offer object
• additionalServices (if selected)
• payments (if applicable)
• Optional include parameters (e.g., fareRules)

6) What Happens Inside Pricing (Commercial Revalidation)

Behind the scenes, the API performs:

• Real-time seat availability revalidation
• Booking class verification
• Fare basis validation
• Tax recalculation
• Airline surcharge recalculation
• Ancillary validation (bags and seats)
• Payment fee validation
• Ticketing deadline refresh
• Booking requirement validation

This step converts an indicative offer into a sellable, commercially validated offer.

Search is informational.
Pricing is transactional validation.

7) Receive the Validated Pricing Response

The response includes:

• Updated flightOffers array
• New base fare
• Updated taxes
• Grand total (final payable amount)
• Ancillary cost breakdown
• Booking requirements
• Ticketing time limits

Important:

The Pricing response becomes the authoritative commercial truth.

Never use Search totals after Pricing.

8) Handle Pricing Outcomes

Scenario A – Price Confirmed

• Totals unchanged
• Proceed forward

Scenario B – Price Changed

• Display price difference
• Require user reconfirmation
• Update checkout amount

Scenario C – Inventory Lost

• Offer invalid
• Force new search

Scenario D – Ancillary Unavailable

• Remove unavailable service
• Prompt reselection
• Reprice

Pricing must always be repeatable and idempotent.

9) Persist the Priced Offer

After successful Pricing:

• Store the full updated flight-offer JSON
• Do not merge with original search data
• Do not recompute totals locally
• Do not rebuild traveler pricing

This exact priced offer must be used for booking.

1. Pricing Is Mandatory Before Booking
2. 1. Never skip Pricing in production.
2. Offer Integrity Is Critical
3. 1. Do not reconstruct or partially rebuild the flight-offer.
3. Every Ancillary Change Requires Repricing
4. 1. Bag change → Reprice
   2. Seat change → Reprice
   3. Payment method change → Reprice
4. Pricing Is Stateless
5. 1. Each request recalculates against live airline inventory.
      
5. Payment Validation Should Happen Early
6. 1. Especially for LCC and card-restricted fares.

Below is a simplified example used in professional Flight booking API for OTA implementations.

Sample Request (POST)

Copy
1{
2 "data": {
3   "type": "flight-offers-pricing",
4   "flightOffers": [
5     {
6       "type": "flight-offer",
7       "id": "125"
8     }
9   ],
10   "payments": [
11     {
12       "brand": "VISA",
13       "flightOfferIds": ["125"]
14     }
15   ]
16 }
17}

Sample Response

Copy
1{
2 "data": {
3   "flightOffers": [
4     {
5       "price": {
6         "currency": "USD",
7         "base": "4300.00",
8         "total": "5463.96",
9         "grandTotal": "5463.96"
10       }
11     }
12   ],
13   "bookingRequirements": {
14     "emailAddressRequired": true,
15     "mobilePhoneNumberRequired": true
16   }
17 }
18}

In real production environments, the response contains:

• Detailed traveler-level pricing
• Segment-level fare mapping
• Tax breakdowns
• Refundable tax amounts
• Paid baggage details
• Paid seat confirmation
• Fare rules (if requested via include parameter)

Paid Bags and Seat Handling

Unlike some systems, ancillaries are embedded directly in the flight offer.

Example:

Copy
1"additionalServices": {
2 "chargeableSeatNumber": "8A",
3 "chargeableCheckedBags": {
4   "quantity": 1
5 }
6}

During pricing:

• Seat availability is validated
• Bag pricing is calculated
• Charges are added to the grand total

Final calculation:

Base Fare

+ Taxes

+ Paid Bags

+ Paid Seats

+ Payment Fees

----------------

= Grand Total

Free seat assignments are not priced or returned.

Pricing Integrity

• Always call Pricing before booking.
• Never trust Search pricing for paymen
• Use only the Pricing response for the checkout display.

Offer Consistency

• Persist the full flight-offer JSON.
• Do not modify traveler order.
• Do not change pricingOptions.
• Do not rebuild fare details manually.

Payment Validation

If working with LCC or card-restricted fares:

• Include the payments object.
• Validate brand compatibility early.
• Handle payment-related repricing gracefully.

Ancillary Repricing

If a user modifies:

• Bags
• Seats
• Payment method

You must reprice before booking.

Search vs Pricing Discrepancy

• Search price is indicative.
  Pricing may return a different total.
• Always surface price changes transparently to users.

Offer Expiry

• Flight offers are time-sensitive.
• Delays between Search and Pricing increase failure risk.

Payment Brand Rejection

• Some airlines reject certain card brands.
• Include payment validation early in the flow.

Ancillary Availability

• Seats may become unavailable between selection and pricing.
• Handle seat repricing logic gracefully.

The Flight Offers Pricing API is the commercial gatekeeper of the Amadeus Quick Connect ecosystem.

It ensures that every booking request:

• Uses validated pricing
• Reflects real-time inventory
• Includes confirmed ancillaries
• Meets airline payment rules
• Enforces mandatory booking data

For travel tech teams building scalable, enterprise-grade flight booking systems, mastering this endpoint is essential.

Search drives discovery.

Pricing ensures transactional integrity.

Together, they form the backbone of a reliable, revenue-protected OTA platform.