A Rare, Data-Driven Look at the True Cost of API Integrations
In the tours & activities space, APIs are the backbone of how supply gets distributed. Which means that, sooner or later, every travel distributor ends up building its own connectivity layer.
Some choose to do it internally. Others rely on external solutions. Both paths exist in the market.
What is less often discussed is the real cost structure behind building and operating those integrations over time.
The Visible Costs of API Integrations
When teams evaluate a new API integration, the focus is usually on a few well-defined phases.
What is often overlooked is that each of these phases actually involves dozens of small tasks, iterations and dependencies.
1. Development
This is not just “building the integration”.
It includes:
- Understanding and interpreting API documentation (often incomplete or inconsistent)
- Mapping data models to your own system
- Finding functionality gaps and remove blockers
- Adapting existing architecture and previous integrations
- Handling edge cases, errors and exceptions
- Building, testing and validating end-to-end flows
In practice, this is a sequence of iterations, not a linear process.
2. Supplier Relationship
Beyond technical work, each integration requires continuous coordination with the provider:
- Getting access to documentation and sandbox
- Managing questions, clarifications and inconsistencies
- Assessing the quality and completeness of testing data
- Iterating based on feedback during certification
This is operational work that sits between product, tech and external teams.
3. Certification & Go-Live
Reaching production is not a single step:
- Passing formal certification processes
- Re-testing in production (sandbox data is often limited or unrealistic)
- Fixing real-world issues post-launch
And importantly: Performance in production depends heavily on efficient design, coding quality, caching strategies and architectural decisions
4. Cloud & Infrastructure
This is also part of the visible cost, though often underestimated.
Each integration adds:
- Processing load
- Storage
- Multiple environments (sandbox + production)
And in production, costs are not only volume-driven, they depend on how efficient your architecture is.
These are expected costs. They go into planning, budgeting, and timelines.
The Overlooked Costs
What is less visible at the beginning is what happens after integrations are live.
This is where APIs become ongoing operational systems.
1. Maintenance & Evolution
APIs change continuously: new versions, deprecated endpoints, and functional updates required by suppliers.
Let’s share some real data : based on our experience at Globick managing multiple integrations, this translates into an average of ~24 maintenance tasks per API, per year, and each of these tasks requires analysis, development, testing and deployment.
This is how that average looks in practice:
- For restech A, we handled 38 maintenance tasks over 2 years
- For restech B, 88 tasks over 3 years
- For restech C, 126 tasks over 4 years
- And for restech D, 64 tasks over 4 years
Different providers, same pattern: a continuous stream of work that doesn’t stop after go-live.
2. Monitoring & Control
APIs don’t fail loudly. They fail silently: availability mismatches, pricing inconsistencies, booking errors… Maintaining reliability requires continuous monitoring, debugging, fixing…
This is ongoing operational overhead.
3. Opportunity cost
Every hour spent building and maintaining integrations internally is an hour not invested in product, growth or commercial capabilities. This is rarely modeled but it’s one of the most relevant costs at scale.
4. The Cost of Getting It Wrong
There is another cost that is rarely quantified, but often far more impactful: the cost of a poorly built integration. APIs don’t just fail technically—they fail commercially. Inefficient caching strategies, slow response times or inconsistent availability can directly impact conversion rates. Even a small drop, such as a 2% decrease in conversion due to latency or inaccurate data, can translate into significant revenue loss at scale. Unlike infrastructure or development costs, this impact is not always visible in dashboards, but it accumulates silently over time. In many cases, the revenue lost due to suboptimal integrations can outweigh the cost of building them properly in the first place.
What Does This Actually Cost?
Let’s translate this into a simple, realistic scenario.
Where the numbers come from
We assume a company that already has a platform in place to manage integrations and a minimum experienced team composed of 1 developer and 1 product / key account profile, 2 people dedicated full time to the job. For this exercise, we’ll use a €60K as the total company cost per person per year, taking Spain as a reference point — a reasonable midpoint between higher-cost markets (such as the US) and lower-cost ones (such as eastern Europe).
We also assume the company plans to implement full-featured integrations.
For each API integration, we assume the following effort distribution:
Effort per API
| Component | Effort Description |
| Development | ~6 weeks + 20% additional time (inefficiencies and project management) |
| Supplier coordination & sandbox certification | ~30% of development time |
| Production go-live & certification | ~20% of development time |
| Maintenance & evolution | ~96 hours/year per API (24 tasks × 4h per task on average) |
| Monitoring & control | ~10% of annual development cost |
| Cloud & infrastructure | ~€400 per API/month (including sandbox + production environments) |
Cost per API
| Cost Component | Year 1 (rounded €) | Recurring ( rounded € / year) |
| Development | 10K€ | — |
| Supplier coordination & sandbox certification | 3K€ | — |
| Production go-live & certification | 2K€ | — |
| Maintenance & evolution
(for a single API) |
14K€ | 14K€ |
| Monitoring & control | 1K€ | 1K€ |
| Cloud & infrastructure | 5K€ | 5K€ |
| Total per API | 35K€ | 20K€ |
What This Looks Like at Scale
Once you scale this model, the numbers add up quickly.
A company managing 25 API integrations over a 5-year period is looking at a total cost of over 2,8M€
With 10 integrations, that still means around 1,2M€ over the same period.
Even with just 5 integrations, the total cost is already close to 600K€.
This is not an edge case.
This is what happens when API integrations become part of your core operations.
What Does This Mean in Time?
If we translate these costs into time, the distinction between building and running integrations becomes clear. For the initial phase, a single API integration typically takes around 8 to 10 weeks end-to-end when combining development, supplier coordination and go-live. For a team handling multiple integrations sequentially, this means roughly 1.5 to 2 integrations per quarter. At scale, building 10 integrations would take close to a full year of continuous work for a small dedicated team, while 25 integrations could extend to 2+ years. Once live, the dynamic changes completely: maintenance becomes an ongoing operational load. Each API requires around 12 working days per year (~96 hours), meaning that 10 integrations already consume 4–5 months of work annually, and 25 integrations require the equivalent of more than a full-time person dedicated exclusively to maintenance. In other words, building integrations is a finite effort—but running them is a permanent one.
“Will Standards and AI development Solve This?”
Partially.
Standards like OCTO or tools like Claude Code or other agentic developments can improve efficiency, especially in the early stages.
From all the chapters laid out before, development and maintenance would be the most benefited from standardization and/or agentic development.
Let’s assume:
- ~50% reduction in development effort
- ~25% reduction in maintenance effort
The overall impact is meaningful, but limited.
Across the full cost structure, this typically translates into ~15–20% total cost reduction.
Why?
Because a large part of the cost does not disappear:
- Monitoring
- Infrastructure
- Supplier-driven changes
- Impact assessment to the current platform
- Ongoing operational work
- and many others
In other words: Standardization and AI can improve how integrations are built, but they don’t fundamentally change the cost of running them over time
Final Thought
APIs are not a one-time project. They are an operational system that grows with your business.
And as the number of integrations increases:
- Complexity compounds
- Costs become structural
- Speed slows down
The real cost is not in building the first integrations. It’s in running them at scale.
How Tour Operators Actually Sell Experiences — And Why Much of the Industry Gets It Wrong
How operators structure their products, how tour operators sell them within travel itineraries, and what experience APIs should learn from hotel APIs - Understanding the structural differences between B2C OTA connectivity and B2B travel distribution
The tours, activities and attractions sector has become one of the most dynamic segments of the travel industry. Over the last decade, experiences have moved from being a secondary element of a trip to becoming one of the main reasons people travel.
Technology has played a major role in this shift. Online platforms have made it easier than ever for travelers to discover and book activities, while reservation systems have helped suppliers digitize their inventory and distribute it globally.
But behind the visible growth of consumer platforms lies another part of the ecosystem that is equally important and often less discussed: B2B distribution.
Travel agencies, traditional tour operators, DMCs, wholesalers and dynamic packaging platforms sell millions of tours and activities every year as part of larger travel itineraries. Their market share is estimated at 11% for 2025 (source : The Outlook for Travel Experiences 2019–2029 from Arival and PhocusWright), meaning $37 billion, with a 10% growth rate YoY
This part of the ecosystem is particularly relevant for large-scale travel distributors — including major tour operators such as Dertour, Avoris, W2M or MTS — whose systems must handle complex itineraries, high booking volumes and strict operational requirements. These bookings may not always attract the same attention as consumer-facing OTAs, but they represent a significant and stable share of the overall market.
Many of the APIs used today to distribute tours and activities were originally designed with B2C marketplaces in mind. And while these APIs work well for consumer discovery and booking flows, they do not always match the operational logic of B2B travel distribution. At the same time, many experiences operators have not structured their product configurations with B2B distribution in mind, often focusing primarily on how their products appear in consumer marketplaces rather than on how they will be integrated and sold within professional travel distribution systems.
As a result, the industry often tries to solve B2B distribution challenges using tools designed for a completely different environment.
The consequences are visible every day: complex integrations, confusing product catalogues, unclear pricing structures and inefficient booking workflows.
To unlock the full growth potential of the experiences sector, it is important to recognize a simple reality: B2B distribution requires a different kind of API.
B2C and B2B: Two very different sales environments
At first glance, selling an experience might seem like a simple transaction. But the context in which that transaction happens fundamentally changes the requirements of the technology behind it.
Understanding these differences is essential when designing distribution infrastructure for the tours and activities sector.
1. How the search process begins
In most consumer-facing OTAs, product discovery starts with a very simple logic: destination plus keywords.
A traveler might search for something like:
“Rome Colosseum tickets”
The platform then displays a list of products related to that search.
These results may include different variations of the same attraction:
- skip-the-line tickets
- guided tours
- small-group experiences
- private visits
- early access options
The objective in this environment is exploration. The traveler wants to compare alternatives before deciding.
In B2B environments, the starting point is usually different. Search often begins with a destination and the composition of the travel group.
For example:
Destination: Rome
Adults: 2
Children: 1 (age 8)
This logic closely resembles the way hotel searches work.
The system needs to know the composition of the group in order to determine:
- which rates apply
- whether the activity is available
- how the final price should be calculated
Instead of simply returning products that match a keyword, the API must immediately validate whether a product can accommodate that specific group configuration.
This means availability and pricing logic need to be applied much earlier in the search process.
2. Standalone purchase vs packaged travel
Another key difference between B2C and B2B environments lies in the role that experiences play in the booking process.
In most consumer platforms, an activity is often the main product being purchased.
The traveler is browsing experiences as the central element of the decision-making process.
But in B2B environments, experiences are frequently just one component of a larger travel package. This is particularly true for large tour operators and packaging platforms that assemble thousands of travel packages every day, combining flights, accommodation and experiences within a single booking flow.
That package may already include:
- flights
- accommodation
- transfers
- insurance
The activity needs to fit smoothly into the itinerary.
In this context, the seller — typically a travel agent, a tour operator system or a dynamic packaging engine — is not looking for dozens of similar options to explore.
They need:
- clear choices
- reliable availability
- quick booking flows
Efficiency becomes much more important than discovery.
Too many options slow down the process of building a travel itinerary.
3. Pricing logic
Pricing structures are another area where the differences between B2C and B2B distribution become very clear.
In B2C marketplaces, prices are normally displayed per person and per ticket type.
The final price is calculated gradually as the traveler selects the number of participants and ticket categories. So the checkout process determines the final total.
In B2B distribution, this model is often impractical.
Travel agents and packaging systems usually need an immediate quote for the entire group. For large tour operators managing high booking volumes, obtaining a clear group price in a single response is essential to maintain fast itinerary building and automated packaging workflows.
Instead of calculating the price step by step, the API must return a result such as:
Total price for this group: €186
This allows the agent to quickly evaluate whether the activity fits within the overall travel package.
Group pricing simplifies the booking process and reduces the risk of manual calculation errors.
4. Product structure and content
Consumer platforms typically have internal teams dedicated to optimizing product listings.
These teams manage:
- content quality
- product mapping
- pricing rules
- catalogue organization
Many B2B distributors do not have this level of internal product management. Instead, they depend directly on the structure and quality of supplier data.
This means APIs must deliver products that are already well organized and easy to interpret.
A clear hierarchy helps ensure smooth integrations:
Product
→ Modality
→ Rates by age group
If this structure is inconsistent or ambiguous, it becomes much harder for distributors to integrate and maintain the catalogue.
5. Choice vs clarity
In B2C environments, offering many alternatives can be beneficial.
A traveler browsing an OTA may appreciate seeing several different options for the same attraction.
But in B2B environments, the situation is different.
Travel agents rarely have time to evaluate dozens of nearly identical products. This becomes even more critical for large-scale distributors whose systems may process thousands of itinerary searches per hour.
When building travel itineraries, they need:
- clear options
- consistent product structures
- minimal duplication
Presenting 20 or 30 similar products for the same attraction often creates confusion rather than value.
In B2B distribution, clarity is far more useful than abundance.
What a B2B-ready API should provide
If the tours and activities sector is to scale effectively within the B2B ecosystem, APIs need to be designed around the operational needs of travel distribution. Several capabilities are particularly important. This is particularly important for global tour operators, wholesalers and large distribution platforms whose technology infrastructure must support large product catalogues and complex packaging logic.
Retail and net pricing
B2B distribution requires flexibility in pricing structures. Some distributors operate with retail prices, while others prefer to work with net rates and apply their own margins.
For this reason, APIs should support both:
- retail rates
- net rates
This flexibility allows distributors to integrate products into their own commercial strategies without additional technical complexity.
Group-based search and pricing
A B2B API must be able to return results based on group composition.
This means the system should:
- validate applicable rates
- confirm availability
- calculate the total price for the group
Ideally, all of this information should be returned within a single response.
Without this functionality, booking workflows become slower and more complex.
Clear product–modality–rate structures
Product information should follow a consistent hierarchy.
A typical structure would be:
Product
→ Modality
→ Rates
Each rate should correspond to a clearly defined age category.
Simple and predictable structures make integrations easier and reduce operational errors.
Simplicity in rate configurations
Overly complex rate structures should be avoided whenever possible.
Examples of complexity that often creates problems include:
- overlapping discounts
- inconsistent age brackets
- multiple special pricing categories
While these structures may seem attractive from a commercial perspective, they often complicate integrations and booking flows.
In B2B distribution, simpler pricing structures tend to scale more effectively.
This is clear product structure, ready for B2B distribution:
This is an example of a product that simply can’t be distributed to B2B wholesalers and tour operators:
Clear definition of age ranges
Age categories must always be clearly defined.
For example:
- Adult: 18+
- Child: 6–17
- Infant: 0–5
Without clear definitions, booking engines cannot reliably calculate prices for different group configurations.
Standardized passenger data requirements
Booking workflows should request only the information that is strictly necessary.
Excessive mandatory questions slow down booking processes and create friction for travel agents.
Passenger data fields should be standardized whenever possible, and additional mandatory questions should be minimized.
Clear pickup point structures
For tours that involve transportation or meeting points, pickup information should follow a clear and consistent structure.
This includes:
- predefined pickup locations
- standardized descriptions
- clear time references
Inconsistent pickup information is one of the most common sources of operational issues in experience bookings.
Multi-item booking capability
B2B transactions often include multiple products within a single itinerary.
For example, a travel package may include:
- accommodation
- transfers
- experiences
An API should ideally support multi-item booking workflows or, at minimum, provide predictable and fast response times when bookings are made sequentially.
Instant voucher delivery
Once a booking is confirmed, the voucher or ticket should be generated immediately.
This is particularly important when experiences are part of larger travel packages.
Delivering documentation instantly ensures that agents can finalize the itinerary without additional manual steps.
Intelligent product selection
One of the biggest challenges in the experiences industry today is product duplication. Multiple suppliers may offer similar tickets for the same attraction.
For B2B distribution, APIs should ideally return:
- a single relevant option
or - a small curated set of options
instead of dozens of nearly identical products.
Reducing duplication helps simplify integrations and improves booking accuracy.
The opportunity ahead
The tours and activities sector still has enormous growth potential. Demand continues to expand as travelers increasingly seek memorable experiences as part of their trips. But scaling this growth across the global travel ecosystem requires infrastructure that reflects how the industry actually operates.
B2B distribution remains a critical channel connecting travelers with experiences around the world. Travel agencies, wholesalers and packaging platforms continue to play an essential role in building complex itineraries that combine flights, accommodation and activities. Large tour operators and wholesalers remain some of the most important buyers of experiences globally, integrating activities into millions of travel packages each year.
For this ecosystem to function efficiently, the underlying technology must evolve.
APIs designed primarily for consumer discovery do not always match the operational needs of professional travel distribution.
Without the right infrastructure, experiences risk being perceived as:
- difficult to integrate
- operationally inconsistent
- technically complex
And when that happens, a significant part of their market potential remains untapped.
Building better infrastructure for the experiences industry
At Globick, we see these challenges every day. Connectivity is not simply about linking systems together, it is about ensuring that those connections work efficiently for the people who rely on them. Many of the integrations we work with involve large-scale distributors and tour operators whose operational requirements are very different from those of consumer marketplaces.
For B2B distribution, this means APIs designed for:
- clarity
- speed
- reliability
When connectivity works properly, the benefits extend across the entire ecosystem:
- Suppliers reach new markets.
- Distributors simplify integrations.
- Travel agents build itineraries more efficiently.
- Travelers enjoy richer travel experiences.
The growth of the experiences sector will continue in the years ahead. But unlocking its full potential requires technology that understands a fundamental difference: browsing an experience is not the same as building a trip around it.