In 2010, a hotel’s technology stack was, in most cases, a single vendor’s product. The PMS handled reservations, check-in, housekeeping, billing, and reporting. Everything else booking engine, channel manager, spa software connected to it through proprietary interfaces that required expensive custom development and ongoing maintenance contracts.
This model is breaking down. Not dramatically, not all at once, but steadily and irreversibly.
What the monolith gave hotels
The monolithic PMS was not irrational. For a hotel operator in 2005, buying one vendor’s complete suite had real advantages: a single support relationship, a single training programme, a single invoice, and the assurance that the components were designed to work together.
The disadvantages were less visible at the time: vendor lock-in that made switching prohibitively expensive, innovation cycles determined by the vendor’s roadmap rather than the hotel’s needs, and integration costs that meant useful adjacent tools revenue management, CRM, guest messaging were either bought from the same vendor (often inferior) or not bought at all.
What the API-first generation looks like
The new generation of hotel technology is built on a fundamentally different model. Systems like Mews, Apaleo, and Cloudbeds are designed from the ground up to expose their data and functionality through well-documented REST APIs. Rather than building everything themselves, they provide the core infrastructure reservations, inventory, rate management, billing and expect an ecosystem of specialist tools to connect around them.
This is the model that has worked in every other software-intensive industry. Salesforce became a platform, not a product. Shopify became a platform. Stripe positioned itself as infrastructure. The hotel industry is going through the same transition, a decade later.
For a hotel running on an API-first PMS, the stack looks different:
API-first PMS (core reservation & billing)
├── Best-of-breed channel manager
├── Specialist revenue management tool
├── Guest messaging platform
├── Housekeeping operations app
├── F&B point-of-sale
└── Custom internal tools (if needed)Each component is the best available tool for its specific job. Each connects to the PMS via a documented API. When a better channel manager launches, you switch no renegotiation with the PMS vendor required.
The HTNG and OHIP layers
The transition to open APIs in hospitality has been complicated by the industry’s legacy of proprietary data formats. HTNG (Hospitality Technology Next Generation) has been trying to standardise messaging formats since 2003. The standards exist OTA message formats, HTNG web service specs but compliance is voluntary and implementation varies widely.
Oracle’s OHIP (Oracle Hospitality Integration Platform) represents the largest single step toward an open ecosystem in the enterprise segment. By exposing Opera Cloud through a documented REST API, Oracle has somewhat reluctantly accepted that the monolith model is ending. OHIP is Oracle’s attempt to become the platform layer rather than be displaced by it.
The tension is real. Every API endpoint Oracle exposes makes it easier for competitors to build on top of Opera. Every integration partner who connects to OHIP is also a potential competitor to Oracle’s own adjacent products. This dynamic explains why OHIP’s documentation is sometimes incomplete and its partner program has friction: Oracle is opening the platform with one hand and protecting its bundle with the other.
What this means for builders
The integration surface is expanding fast. Two years ago, building a hotel tech product meant choosing between Opera (enterprise), Mews/Apaleo (mid-market modern), and Cloudbeds (independent). Today, there are meaningful APIs across the stack: channel managers with developer programs, revenue management systems with recommendation APIs, guest messaging platforms with webhooks. The connective tissue of the industry is becoming programmable.
Abstraction layers are becoming viable. For most of hospitality technology’s history, building a product that worked across multiple PMS systems required maintaining separate integrations for each Opera, Mews, Cloudbeds each requiring different code. As these systems converge toward REST and webhooks, abstraction becomes tractable. A few companies (Hapi, Impala, Apaleo’s open ecosystem) are building exactly this: a unified hospitality data layer that normalises across PMS systems. If these platforms gain traction, the development cost of building hotel tech drops substantially.
Smaller hotels become accessible markets. The old model favoured large properties the integration costs were only justifiable at scale. The API-first model brings smaller properties into reach. A 30-room boutique hotel on Cloudbeds has the same API surface as a 300-room hotel. The addressable market for hotel tech products expands downmarket.
Data portability becomes a selling point. When a hotel’s data lives in an accessible API rather than a vendor’s proprietary database, switching costs fall. A hotel that can export its full reservation history, guest profiles, and rate data via API can evaluate competing systems on merit rather than migration difficulty. Vendors who resist this are signalling that their competitive moat is lock-in, not quality. Hotels are starting to notice.
The transition is not uniform
The open stack future is not evenly distributed. Large branded hotels the Marriotts, Hiltons, and IHGs of the world have technology teams and IT budgets that allow them to build custom integrations and operate complex stacks. Their technology decisions happen on 5-10 year cycles and are driven as much by contract relationships as technical merit.
Independent hotels and boutique groups are moving faster. Without legacy infrastructure and enterprise procurement processes, they can and do switch systems when better tools emerge. Mews’s fastest-growing segment is mid-market independents who are replacing legacy systems with cloud-native alternatives.
The transition zone mid-market branded hotels and regional chains is where the interesting competition is happening. These properties have enough complexity to need serious infrastructure but enough flexibility to evaluate new options. They are the battleground where the next generation of hospitality technology will be decided.
What I’m watching
Three things will determine how quickly the open stack model wins:
Whether OHIP becomes genuinely open. If Oracle commits fully to OHIP as a platform competitive neutrality, complete documentation, reasonable pricing it accelerates the ecosystem. If they continue to use it as a defensive tool, specialist PMS vendors will continue to take market share in the segments they can reach.
Whether abstraction platforms gain traction. If Hapi, Impala, or a competitor successfully normalises the PMS API surface, the development cost of building hotel tech drops dramatically and new entrants multiply. This is the moment the market opens up.
Whether hotels start demanding portability. The single most powerful forcing function for open APIs is hotel operators who make data portability a requirement in procurement. When hotels start asking “can I export all my data via API at any time?” as a standard contract question, the vendors who can’t say yes will lose deals. That moment is coming. The engineers building today should assume it arrives sooner than the vendors expect.