Amadeus API Alternatives: What Changed When Self-Service Closed, and What to Use for Hotels

Amadeus closed its Self-Service developer portal on July 17, 2026, and every Self-Service API key stopped working that day.
The online signup, the free test environment, and the pay-per-request hotel endpoints went with it; Amadeus's Enterprise APIs, sold through contracts, carry on.
If you searched for the Amadeus API and found keys that no longer authenticate, or hotel docs that now redirect to the developer home page, that's why.
Two crowds land here: teams building booking flows, and a growing share who want hotel data, meaning market rates, OTA prices, hotel reviews, and availability trends.
This guide covers what changed, what Enterprise still offers for hotel work, and the Amadeus API alternatives for each job, including the jobs where Amadeus remains the right answer.

Key Takeaways

• Self-Service closed on July 17, 2026. Keys were disabled, new signups had already stopped, and only Enterprise contracts remain.
• Amadeus is still excellent at its core job. Booking flows, GDS content, and flight-plus-hotel products, now behind an Enterprise sales cycle.
• Its hotel inventory is distribution inventory. GDS-contracted rates for bookable channels, which often differ from what consumers see on OTAs.
• Prototyping a booking flow needs a new on-ramp. Some bed banks still issue evaluation keys online; GDS access starts with a sales conversation.
• Consumer-channel data sits outside its scope. OTA prices, full review text, and market rate intelligence need a different source.
• The mature setup mixes stacks. An Enterprise GDS contract or a bed bank for the booking pipe, an OTA data API for the intelligence layer.

What the Amadeus Hotel APIs Actually Offer

Until July 17, 2026, Amadeus split its offering into two tiers.
Self-Service was the one developers met first: sign up online, get a free API key, build against a test environment with monthly call quotas, then pay per request in production.
Amadeus announced the decommission in February 2026, paused new registrations, and switched the keys off on the shutdown date (migration notes).
For reference, these are the hotel endpoints Self-Service exposed:

What remains is the Enterprise tier: the full GDS, with negotiated content, ticketing, and corporate travel infrastructure, sold through contracts and an enterprise sales cycle.
For hotel work, that's the same kind of inventory behind a contract instead of a signup form.
That context is the key to the whole fit question.
Amadeus's hotel inventory is distribution inventory: properties bookable through GDS channels, at GDS-contracted rates.
That's the design, and it's also why the data looks nothing like the consumer OTA world.
The rate Amadeus returns for a property is frequently a different number from what a traveler sees on Booking.com, Expedia, or the hotel's own site, because different contracts flow through different channels at different prices.

The Limits Developers Actually Hit

Every limit below is structural rather than a bug, and each one traces back to the GDS heritage.
Access now starts with sales.
With Self-Service gone, there's no online signup and no test environment; evaluating Amadeus hotel content means an Enterprise conversation before the first request.
What the data is really like only becomes visible after that contract, which is late in an evaluation to learn it.
Coverage skews away from the OTA world.
GDS-distributed inventory leans toward chains and business-travel properties.
Independent hotels, apartments, and OTA-only listings are patchy, so if your use case is "the hotels travelers actually see on Booking.com", the catalogs diverge significantly.
Consumer rates are structurally absent.
What Booking.com, Expedia, or Agoda charge, member and mobile rates, the hotel's direct-site price: none of it flows through GDS contracts.
Rate intelligence against consumer channels can't be built on GDS rates, whatever the request volume.
Reviews are thin.
Hotel Ratings returns aggregated sentiment scores for a subset of properties.
Full review text and per-review metadata aren't part of the product, so review aggregation and sentiment pipelines need a different source.
Enterprise onboarding carries real friction.
Contracts and verification come first, and booking endpoints add compliance weight around payment handling and, depending on your market, consolidator relationships.
For a booking product, that weight is reasonable.
For a data experiment, it's a lot of process to discover what the data looks like.
If you're mid-evaluation with the Amadeus docs open in the next tab, check each of these against the current pages; the specifics evolve, and the pattern has held.

The Fit Test: Is Amadeus Right for Your Use Case?

The one-sentence rule: if your product books rooms, evaluate Amadeus seriously, and if your product analyzes the hotel market, you need consumer-channel data that Amadeus doesn't carry.

Amadeus API Alternatives, by Use Case

Honest routing means naming alternatives that have nothing to do with us, so that's where this starts.
For booking flows, the real alternatives are other inventory providers.
Expedia's partner program (approval-gated, covered in our Expedia data guide), bed banks like Hotelbeds, which still issues evaluation keys online with a quota of 50 requests a day, and the other GDS players on the Sabre and Travelport side.
Different inventory mixes, same product category; our hotel booking API guide maps all six supplier types and who qualifies for each.
For OTA rates, availability, and market data, the job needs an OTA data API.
This is the consumer-channel work: live rates and availability for any public property across Booking.com, Expedia, Google's hotel results (direct rates included), Agoda, TripAdvisor, and Airbnb.
StayAPI is built for exactly this segment: signup with 50 free requests, no approval cycle, and production data from the first request, with no Enterprise sales cycle in front of it.
For reviews and sentiment, OTA review endpoints carry the depth.
Full review objects per platform: Booking.com's positive/negative split, TripAdvisor's narrative text, Agoda's reviewer nationality field.
For enrichment and reference data, Google's surfaces fill the Hotel List gap.
Photos, basic info, and coordinates come from Google's hotel results; our Google Hotels API guide maps that side.
The mature answer for travel products is a mixed stack.
An Enterprise GDS contract (or a bed bank) as the booking pipe, an OTA data API as the intelligence layer.
They're complements, and teams that force one vendor into the other's job end up rebuilding the missing half anyway.
The same split shows up across Booking.com's own API programs: every official surface serves its platform's business model, and the analytics layer comes from somewhere else.
The routing, condensed:

Getting Started with the Data-Side Evaluation

If your job landed in the data rows of the fit table, here's an evaluation you can run today without a sales call:
1. Sign up at stayapi.com: 50 free requests, no credit card, production data immediately.
2. Pick 3 properties you know well, ideally ones you priced through Amadeus before.
3. Pull their rates from 2 or 3 OTAs plus Google's hotel results for the same dates, and compare against what a browser shows.
Here's the shape of one of those calls, against the Booking.com prices endpoint:

curl -X GET "https://api.stayapi.com/v1/booking/hotel/prices?hotel_id=4045490&check_in=2026-11-12&check_out=2026-11-14&currency=USD" \
  -H "x-api-key: YOUR_API_KEY"

{
  "success": true,
  "data": {
    "hotel": { "name": "Maxime Boutique Hotel Avenida da Liberdade" },
    "pricing_summary": { "price_per_night": "$189", "currency": "USD" },
    "rooms": [ { "room_name": "Deluxe Double Room", "is_refundable": true } ],
    "is_soldout": false
  }
}

The Google Travel prices endpoint returns the same property as an offers array (each booking site, its price, the direct rate when advertised), so the GDS-rate-versus-consumer-rate delta becomes visible in one sitting.
You can also preview the data with no code via the free hotel search tool, or wire the daily version of this pull into N8N or Make.com; the full build lives in our hotel price tracker guide.
For teams evaluating a full stack (booking pipe plus data layer), book a demo.

FAQ

What happened to the Amadeus Self-Service API?

Amadeus decommissioned it on July 17, 2026.
The portal closed, new signups had already stopped, and every Self-Service API key was disabled.
Enterprise customers kept their access through the Enterprise portal.

Is the Amadeus API free?

Not in any self-serve form since July 17, 2026.
Self-Service had a free test environment and pay-per-request production, and both closed with the portal.
What remains is Enterprise, which is contract-based.

Does the Amadeus API include OTA prices like Booking.com or Expedia?

No.
Amadeus returns GDS-distributed rates, which are often different numbers from what consumers see on OTAs or hotel websites.
Consumer-channel rates come from OTA data sources; StayAPI is one example.

Does Amadeus provide hotel reviews?

Self-Service had a Hotel Ratings API with aggregated sentiment scores for a subset of properties, and it closed with the rest of Self-Service.
Review aggregation and sentiment analysis need OTA review endpoints, which return complete review objects.

What is the best Amadeus alternative for hotel data?

It depends on the job.
For booking flows, the alternatives are other inventory providers: Expedia's partner program, bed banks (some issue evaluation keys online), and other GDSs.
For rates, availability, and reviews across consumer channels, an OTA data API like StayAPI covers what GDS inventory can't.

Can I use Amadeus and an OTA data API together?

Yes, and it's the common production pattern: Amadeus Enterprise handles the booking pipe while an OTA data API feeds pricing intelligence, parity monitoring, and reviews.
The two layers answer different questions about the same hotels.