Target PMS APIs
Working proposal
This page presents a preliminary survey of Property Management System (PMS) APIs selected for reverse-engineering as part of the UHDM project. The goal is to identify recurring domain patterns, not to exhaustively catalogue every API.
Introduction
To infer a universal hospitality domain model, we must study how existing systems expose their data and operations. The APIs of leading PMS vendors provide valuable insight — each reflects different architectural choices, naming conventions, and assumptions about the hospitality domain.
However, these APIs vary greatly in scope, style, and terminology. For example, Mews offers four separate APIs with distinct architectures and vocabularies, whereas Apaleo delivers a suite of RESTful APIs designed around functional areas such as Booking, Finance, and Profile.
The purpose of this analysis is therefore to:
- Audit a representative sample of PMS APIs.
- Capture comparable metadata about their design and domain structure.
- Understand how these differences affect our reverse-engineering methodology.
Audit framework
Each API will be documented consistently using the following criteria:
| Category | Key questions |
|---|---|
| General | Vendor, API name/version, base URL, authentication, access requirements |
| Scope | Which functional areas are covered? (PMS operations, distribution, direct booking, POS, etc.) |
| Architecture | REST (strict or RPC-style), GraphQL, SOAP, hybrid? JSON or XML payloads? |
| Documentation quality | Public? Interactive? Auto-generated or curated? |
| Schema availability | OpenAPI/Swagger? GraphQL schema? Postman collection? |
| Domain entities | What core entities are defined (Guest, Booking, Rate, Invoice, etc.)? |
| Model quality | Normalized or nested? Clear relationships? Use of UUIDs vs numeric IDs? |
| Integration support | Webhooks, message queues, change streams? |
| Extensibility | Custom fields, metadata, external references? |
| Consistency & naming | Are naming conventions coherent across endpoints? |
| Maturity | Versioning, deprecation policy, rate limits, sandbox availability? |
Note on complexity
The framework above defines the full range of dimensions considered in the UHDM audit. In early iterations, only a subset may be completed for each API. Deeper dimensions will be added progressively as the analysis matures. This approach ensures that all audits remain comparable while keeping the initial workload manageable.
Deliverables will include:
- PMS API audit summary
- Links to documentation and schema sources
- Stored OpenAPI definitions (where available) in the project resources directory
Candidate PMS APIs
The current selection represents different market segments and design philosophies. The intention is to analyze 4 to 6 APIs — enough to expose recurring patterns without overwhelming scope.
| Vendor | APIs | Public access? | Notes |
|---|---|---|---|
| Apaleo | Booking, Finance, Profile, Rates | ✅ (OpenAPI) | API-first design, clean semantics, RESTful architecture |
| Mews | Connector, POS, Booking Engine, Channel Manager | ✅ (OpenAPI for most) | Modern, multi-API design; RPC-style JSON over POST |
| Cloudbeds | PMS API | ⚠️ Partner access required | Mid-market representative, REST-based |
| Oracle Hospitality (OPERA Cloud) | OHIP | ⚠️ Controlled access | Enterprise example; mix of SOAP legacy and REST |
Additional systems may be considered later (for example Protel, RoomRaccoon, Guestline, StayNTouch) to improve coverage and confirm recurring domain patterns.
Preliminary observations
Mews
Mews exposes four distinct APIs that together cover the PMS ecosystem:
| API | Description | Style | Schema |
|---|---|---|---|
| Connector API | General operations across reservations, guests, and finance | JSON-RPC style over HTTP POST | ✅ Public OpenAPI |
| Channel Manager API | OTA distribution and booking connectivity | JSON-RPC style | ❌ No OpenAPI |
| Booking Engine API | Direct booking and property availability | JSON-RPC style | ✅ Public OpenAPI |
| POS API | Point-of-sale operations for outlets | JSON:API compliant REST | ✅ Public OpenAPI |
This diversity highlights how even within a single vendor, domain scope and language can diverge. For instance, Property in the Connector API becomes Hotel in the Booking Engine API. The Connector API alone spans roughly seventy pages of documentation, with a correspondingly large OpenAPI definition — an excellent but demanding target for reverse-engineering.
Apaleo
Apaleo offers a cohesive suite of RESTful APIs organized by functional area, all documented through a unified Swagger interface and downloadable OpenAPI definitions.
| Category | Example APIs | Description |
|---|---|---|
| Business APIs | Booking, Finance, Payment, Distribution, Profile | Core PMS operations and integrations |
| Development APIs | Identity, Webhooks, UI Integration | Extend and automate the PMS |
| Setup APIs | Inventory, Rate Plan, Settings | Automate configuration and property rollout |
Apaleo’s model is modular but conceptually consistent — each API follows REST conventions and a common domain language. This makes it an ideal counterpoint to Mews for comparative modeling.
Challenges and variation
The preliminary survey reinforces that 'a PMS API' is not a singular concept.
APIs differ in:
- Granularity — one large general-purpose API (Mews Connector) vs. many narrow APIs (Apaleo).
- Architectural style — RPC-style JSON vs. RESTful resource orientation.
- Domain language — “Hotel” vs. “Property”, “Booking” vs. “Reservation”.
- Schema exposure — public OpenAPI definitions vs. closed partner documentation.
These differences mean each PMS requires a slightly different reverse-engineering approach:
- JSON-RPC APIs must be parsed by operation payloads rather than resource paths.
- REST APIs can often be analyzed directly from their OpenAPI schemas.
- For closed or hybrid APIs, models may need to be inferred manually from documentation.
Future direction
The next steps for this strand of work are to:
- Complete the initial audit of the four selected APIs.
- Extract and normalize entities from at least two (Mews and Apaleo).
- Identify early cross-system correspondences (for example
Reservation ↔ Booking,Customer ↔ Guest). - Begin defining structural archetypes — flat vs. nested booking models, guest identity handling, etc.
The outcomes of this audit will directly inform the UHDM Conceptual Layer, from which the stable sub-domains and canonical ontology will emerge.
Read next: Sub-domains