Amadeus Self-Service REST API vs Enterprise REST API is an important comparison for travel startups, OTAs, developers, and enterprise travel companies choosing an Amadeus integration model. The right option affects API access, pricing, rate limits, flight booking capabilities, support, scalability, and long-term platform architecture.
For a startup building its first flight search application, Self-Service may be enough.
For an established OTA, corporate travel platform, or high-volume travel company that needs deeper inventory, servicing capabilities, commercial support, and a larger API catalog, Enterprise access may be the better fit.
PHPTRAVELS works with travel businesses integrating airline and travel inventory into B2B, B2C, and corporate booking platforms. This guide explains the difference in practical terms so you can choose an Amadeus access model based on your actual business requirements.
What is the difference between Amadeus Self-Service and Enterprise APIs?
The short answer: Amadeus Self-Service is designed primarily for developers, startups, testing, and relatively straightforward travel applications, while Amadeus Enterprise is designed for travel companies that require broader API access, customized commercial terms, dedicated account support, and more advanced operational capabilities.
For the latest production, pricing, support, and API access details, check the official Amadeus Self-Service API documentation.
Here is the difference at a glance:
| Area | Amadeus Self-Service | Amadeus Enterprise |
|---|---|---|
| Best for | Developers, startups, MVPs, smaller applications | OTAs, established agencies, enterprises, high-scale platforms |
| Access | Developer onboarding | Request and commercial approval |
| API catalog | Selected APIs | Broader/full Enterprise catalog |
| Main format | REST/JSON | Depends on Enterprise product and service |
| Test environment | Available | Depends on contracted Enterprise solution |
| Production pricing | Free quota + pay-as-you-go usage | Customized commercial pricing |
| Rate handling | Published Self-Service network limits | Depends on Enterprise agreement/product |
| Support | Documentation, developer support channels | Dedicated account management |
| Flight booking | Available with additional production requirements | Broader workflows depend on contracted services |
| Ticketing | Typically requires a consolidator for Self-Service flight booking | Depends on agency setup and commercial arrangement |
| SLA | No universal public Self-Service SLA | Service commitments are contract-specific |
| Best long-term fit | Fast development and selected use cases | Larger, operationally critical travel platforms |
The important point is that Enterprise is not simply a faster version of Self-Service. The commercial relationship, API availability, support model, and operational possibilities can be different.
What is the Amadeus Self-Service API?
The Amadeus Self-Service API is a developer-focused travel API offering that makes it relatively easy to start building applications using Amadeus travel data.
Developers can create an account, create an application, obtain credentials, test APIs, and later request production access.
The Self-Service catalog includes APIs covering areas such as flights, hotels, cars and transfers, destination experiences, itinerary management, and market insights. However, it represents a selected API catalog rather than the complete Amadeus Enterprise portfolio.
If you are unfamiliar with how supplier connections fit into a booking platform, our guide to travel APIs explains how different travel inventory sources connect with booking software.
Who should use Amadeus Self-Service?
Self-Service is usually a logical starting point for:
- Travel technology startups
- Independent developers
- MVPs and proof-of-concept projects
- Flight search applications
- Small booking platforms
- Businesses testing an Amadeus integration
- Development teams that want REST/JSON APIs without beginning with an Enterprise commercial agreement
Its main advantage is speed of development.
You can validate whether Amadeus data and APIs suit your application before committing to a more complex commercial or technical setup.
How does Amadeus Self-Service authentication work?
Amadeus Self-Service uses OAuth 2.0 Client Credentials authentication.
After creating an application, you receive an API key and API secret. Your server exchanges these credentials for an access token, and the token is then included in API requests.
This is more accurate than describing Self-Service authentication as simply “using an API key.” The key and secret are credentials used to obtain an OAuth access token.
For production systems, API secrets should remain server-side and should never be committed to public repositories.
Amadeus specifically warns that publicly exposed credentials may be revoked to protect accounts from unauthorized usage and unexpected API charges.
Does Amadeus Self-Service provide a test environment?
Yes.
New Self-Service applications can use an Amadeus test environment before moving to production.
However, developers should understand an important difference:
Test data is not the same as production data.
The test environment uses limited datasets and may include cached or restricted results for individual APIs. Production provides broader real-time data appropriate for live applications.
That means a flight route or hotel result that is unavailable in testing does not automatically mean it will be unavailable in production.
The test environment is intended primarily for:
- API development
- Authentication testing
- Request and response validation
- UI development
- Error handling
- Booking-flow prototyping
It should not be used to judge the full commercial inventory available to a live application.
What are the Amadeus Self-Service API rate limits?
This is one area where the previous version of this article needed clarification.
Amadeus currently documents the following general Self-Service network limits:
| Environment | Published Rate Limit |
| Test | 10 transactions per second |
| Production | 40 transactions per second |
Amadeus' developer documentation currently lists 10 TPS for test and 40 TPS for production. These limits should always be rechecked before designing a high-volume system because API policies can change.
A rate limit is also different from a monthly billing quota.
Rate limit vs API quota: what is the difference?
A rate limit controls how quickly requests can be sent.
A quota determines how many requests may be included free or available within a particular usage allowance.
Self-Service test environments include monthly free request quotas. Production also retains free request quotas for individual APIs, after which additional production usage can be billed.
That distinction matters when calculating infrastructure requirements.
A growing OTA should therefore monitor both:
- Requests per second during traffic peaks
- Total API consumption over the billing month
Applications should also handle HTTP 429 Too Many Requests responses correctly rather than repeatedly retrying requests without control.
How much does the Amadeus Self-Service API cost?
Self-Service uses a free-quota plus pay-as-you-go model in production.
Amadeus provides free monthly request quotas for Self-Service APIs. When production usage exceeds the applicable free quota, additional API calls are charged according to the rate for that particular API.
There is therefore no single universal price for “the Amadeus API.”
Cost depends on:
- Which API endpoints you use
- Number of calls
- Search volume
- Pricing calls
- Booking transactions
- Order-management activity
- Your overall application architecture
A flight booking engine, for example, can generate multiple API calls during one customer journey.
A traveler may:
- Search flights
- Change dates
- Search again
- Select an offer
- Confirm current price
- Submit traveler information
- Create an order
- Retrieve the booking later
This is why API cost per booking is often more useful than API cost per request when planning an OTA's economics.
If you are designing that workflow, see our complete guide to flight API integration.
Is Amadeus Self-Service production unlimited?
There is no general monthly consumption cap in production according to Amadeus' current Self-Service FAQ, provided billing requirements are satisfied.
That does not mean there are no controls.
Production usage remains subject to network rate limits, payment status, API-specific requirements, commercial conditions, and the availability of individual services.
This distinction is important because saying “Self-Service has fixed usage limits” can be misleading.
A better description is:
Self-Service production can scale beyond the free monthly quota through pay-as-you-go billing, but applications must still operate within applicable technical and product-level restrictions.
Can you book flights with Amadeus Self-Service APIs?
Yes, but production flight booking has additional requirements.
A typical Self-Service flight booking flow can involve:
- Flight Offers Search
- Flight Offers Price
- Flight Create Orders
- Flight Order Management
If your platform needs a complete booking experience rather than flight search alone, these services need to be connected into a structured transaction flow.
Our flight booking software page shows how these supplier APIs fit inside an actual customer and agent booking experience.
Do you need a consolidator for Self-Service flight ticketing?
For Self-Service production use of Flight Create Orders, Amadeus states that businesses need an arrangement with an airline consolidator for ticket issuance unless they operate with the required certification/setup.
Amadeus also applies market and regulatory requirements to production flight booking.
This is one of the most important points for new OTAs.
An API that creates a flight booking is not automatically the same thing as having complete ticketing authority.
Before building your production architecture, determine:
- Who creates the PNR?
- Who issues the ticket?
- Who handles schedule changes?
- Who manages refunds?
- Who handles exchanges?
- Who manages voids?
- Who provides after-sales support?
These operational questions often matter more than the initial flight-search integration.
What are the limitations of Amadeus Self-Service?
Self-Service is useful, but it does not provide everything available across the broader Amadeus ecosystem.
Common limitations to consider include:
1. Selected API catalog
Self-Service provides selected APIs rather than the complete Enterprise API portfolio.
2. Limited test data
The test environment intentionally provides limited or cached datasets for many services.
3. Published network rate limits
Traffic-intensive applications need appropriate caching, request management, queueing, and retry logic.
4. Flight ticketing requirements
Production flight booking may require a consolidator and compliance with market-specific requirements.
5. Post-booking limitations
Certain post-ticketing operations may need to be handled through your consolidator rather than entirely through the Self-Service API flow.
6. Support model
Self-Service users primarily rely on documentation, community/developer channels, and support forms rather than a dedicated Enterprise account-management relationship.
These limitations do not make Self-Service unsuitable.
They simply mean you should choose it based on your workflow rather than assuming every Amadeus capability is automatically included.
What are Amadeus Enterprise APIs?
Amadeus Enterprise APIs are designed for businesses that need broader access to Amadeus technology, customized commercial arrangements, and dedicated account support.
Amadeus describes Enterprise as providing access to its broader API catalog for organizations with scaling requirements and established travel brands. Access is granted on request and may include special requirements.
It is also worth clarifying the terminology.
People frequently search for “Amadeus Enterprise REST API,” but Amadeus refers more broadly to Enterprise APIs. The exact technology and interfaces available depend on the specific Amadeus product being contracted.
Enterprise should therefore be viewed as a commercial and technology access model rather than one single API endpoint.
For a deeper implementation-focused explanation, see our Amadeus Enterprise API integration guide.
Who should consider Amadeus Enterprise?
Enterprise access is more relevant when your organization:
- Operates a high-volume OTA
- Has substantial flight-search traffic
- Needs capabilities outside the Self-Service catalog
- Requires deeper booking and servicing workflows
- Operates across several markets
- Needs dedicated commercial support
- Requires a direct relationship with Amadeus
- Has complex airline distribution requirements
- Needs negotiated commercial conditions
- Treats the booking platform as mission-critical infrastructure
Businesses comparing Amadeus with other distribution technologies may also find our guide to GDS systems for travel agents useful for understanding where systems such as Amadeus fit within travel distribution.
How much does Amadeus Enterprise API cost?
Amadeus does not publish one universal Enterprise API price because Enterprise pricing is customized.
The commercial arrangement may depend on factors such as:
- Products required
- Transaction volume
- Markets
- Business model
- Content requirements
- Support requirements
- Booking volume
- Implementation scope
- Contractual terms
Amadeus publicly describes Enterprise pricing as customized rather than pay-as-you-go at a single public rate.
Therefore, websites claiming one fixed “Amadeus Enterprise API price” should be treated carefully.
There are also two separate costs to consider:
Amadeus access cost
This is determined by your commercial arrangement with Amadeus.
Integration cost
This covers the software work required to connect Amadeus with your website, booking engine, admin panel, payments, markups, agents, reporting, notifications, and other business systems.
They are not the same expense.
PHPTRAVELS' Amadeus API integration solution focuses on the second part: connecting the API into an operational travel booking platform.
Does Amadeus Enterprise provide an SLA?
The safest answer is:
Enterprise service and support commitments depend on the commercial agreement.
Amadeus' public developer documentation confirms that Enterprise customers receive dedicated account-management support and customized commercial arrangements, but it does not publish one universal SLA that applies to every Enterprise customer or API.
If uptime or response time is business-critical, ask Amadeus to define contractually:
- Availability commitments
- Support response times
- Escalation procedures
- Incident management
- Maintenance notifications
- Service credits, where applicable
- API versioning and change policies
- Recovery expectations
Do not design an enterprise booking operation around an assumed SLA that is not included in your actual contract.
Is Enterprise always faster than Self-Service?
Not necessarily.
Enterprise should not automatically be interpreted as “the same API with faster response times.”
Performance depends on:
- API being called
- Search complexity
- Origin and destination
- Number of passengers
- Supplier response times
- Network latency
- Application architecture
- Caching strategy
- Number of downstream services
- Commercial/product configuration
The stronger reason to choose Enterprise is typically capability, scale, support, commercial alignment, and access, rather than assuming every API request will simply return faster.
Self-Service vs Enterprise: which has better API coverage?
Enterprise has broader API coverage.
Amadeus explicitly describes Self-Service as a selected catalog and Enterprise as providing access to its broader/full API catalog.
That difference becomes important when a company progresses beyond basic search and booking.
A mature travel platform may eventually require:
- Advanced fare information
- Broader airline content
- More detailed fare rules
- Servicing workflows
- Additional reservation capabilities
- Specialized travel products
- Corporate travel features
- Operational tools
- More complex post-booking processes
This is why API selection should begin with your required booking lifecycle rather than with the API name.
Which API is better for a travel startup?
For most early-stage development and validation projects, Self-Service is the easier starting point.
It allows a team to:
- Start development quickly
- Test REST APIs
- Build a proof of concept
- Validate flight or hotel search
- Estimate API usage
- Test customer demand
- Understand booking architecture
A startup should normally avoid Enterprise complexity until there is a clear requirement for it.
However, if the startup's entire business model depends on functionality that exists only through Enterprise access, starting with Self-Service may create unnecessary rework.
Define the required workflow first.
Which API is better for an OTA?
It depends on the OTA's scale and booking requirements.
A small OTA may be able to operate with Self-Service when its required APIs, markets, consolidator arrangement, and transaction volumes fit the model.
Enterprise becomes more relevant when an OTA needs:
- Broader Amadeus products
- More complex flight operations
- Dedicated account management
- Customized commercial terms
- Enterprise-level operational alignment
- Larger-scale travel distribution
An OTA also rarely operates on the API alone.
The API must connect with a travel booking software layer that handles user accounts, markups, payments, bookings, agents, confirmations, reports, and administration.
Can you migrate from Amadeus Self-Service to Enterprise?
Yes, but it should be treated as a new commercial and technical phase rather than a simple account upgrade.
Amadeus confirms that businesses can potentially use APIs from both catalogs, but the requirements and conditions of the two offerings are different. The Self-Service team also states that Enterprise access is managed separately by the appropriate Amadeus business teams.
A migration may require changes to:
- Credentials
- API endpoints
- Request structures
- Response mapping
- Fare processing
- Booking logic
- Error handling
- Ticketing workflow
- Servicing workflow
- Monitoring
- Commercial reporting
This is why a clean integration layer is important.
Your customer-facing booking engine should not be tightly coupled to one supplier's raw response format.
Can a travel platform use both Self-Service and Enterprise APIs?
Potentially, yes.
Amadeus itself notes that APIs from both catalogs can potentially be used, although the requirements and commercial conditions differ.
From an architecture perspective, your travel platform should ideally normalize supplier data behind a common integration layer.
For example:
Amadeus → Integration layer → Booking engine → Website/app
instead of:
Website → Raw Amadeus API responses
The first model makes it easier to introduce another supplier later.
If you expect to connect several GDSs, NDC providers, hotel suppliers, or aggregators, a broader API integration architecture is usually safer than building each provider directly into the frontend.
What should you check before choosing Self-Service or Enterprise?
Before making a decision, answer these questions.
1. Do you need search only or actual booking?
Search applications have very different requirements from complete booking platforms.
2. Who will issue airline tickets?
If you use Self-Service flight booking, understand the consolidator and ticketing requirements before development begins.
3. What markets will you operate in?
Flight booking requirements and availability can vary by market.
4. What is your peak API traffic?
Do not calculate only monthly traffic. Measure peak transactions per second.
5. Which Amadeus APIs do you actually need?
Create an endpoint list before choosing the access model.
6. Do you need post-booking automation?
Changes, cancellations, exchanges, refunds, and ticket servicing can make the difference between a simple booking website and an operational OTA.
7. What happens if Amadeus is unavailable?
Your application should have sensible timeouts, retries, error handling, monitoring, and customer messaging.
8. Will you add other suppliers later?
Many travel businesses eventually use several content sources.
Designing for multiple suppliers early can reduce expensive redevelopment later.
Which Amadeus API should you choose?
Use this simple decision framework.
Choose Amadeus Self-Service when:
- You are building an MVP
- You want fast REST API access
- You are still validating your business model
- Your required APIs exist in the Self-Service catalog
- Your traffic fits the published technical limits
- You can work within Self-Service booking and ticketing requirements
- You prefer pay-as-you-go production usage
Consider Amadeus Enterprise when:
- Your platform already operates at significant scale
- You need services unavailable through Self-Service
- You require a broader Amadeus API relationship
- You need dedicated commercial/account support
- Your travel operation is business-critical
- You need customized commercial arrangements
- You have complex booking or servicing requirements
Consider a multi-supplier architecture when:
- You do not want one supplier to be your only inventory source
- You sell in multiple regions
- You need different airline or hotel content sources
- You want supplier redundancy
- You need to compare commercial inventory
The right answer is therefore not always “Self-Service or Enterprise.”
For some OTAs, the right answer is Amadeus plus additional travel suppliers managed through one booking platform.
FAQs
Is the Amadeus Self-Service API free?
Is Amadeus Self-Service suitable for production?
What is the Amadeus Self-Service production rate limit?
Does Amadeus Self-Service use REST API?
Does Amadeus Self-Service use API keys or OAuth?
Can I book and ticket flights using Amadeus Self-Service?
Is Amadeus Enterprise more expensive than Self-Service?
Does Amadeus Enterprise have higher rate limits?
Can I upgrade from Self-Service to Enterprise later?
Do I need Enterprise API access to build an OTA?
Final Verdict: Amadeus Self-Service or Enterprise?
There is no universally better Amadeus API model.
Self-Service is better when speed, developer accessibility, REST APIs, testing, and flexible usage-based production access are the priority.
Enterprise is better when your business requires broader Amadeus capabilities, dedicated account support, customized commercial terms, and an access model designed around a larger travel operation.
The most important step is to map your complete booking lifecycle before choosing either option.
Do not evaluate only flight search.
Evaluate:
Search → pricing → fare validation → booking → payment → ticketing → confirmation → servicing → cancellation → refund → reporting.
Once those requirements are clear, the correct API strategy becomes much easier to identify.
Need to integrate Amadeus with your travel platform?
PHPTRAVELS can connect Amadeus with a complete B2B or B2C travel booking workflow rather than leaving you with raw API responses.
You can explore the Amadeus API integration options, review available platform features, or compare PHPTRAVELS pricing.
If you want to see how the booking workflow works before deciding, you can also request a live demo.