Apaleo · PMS Power Index

Composite score: 77.0 / 100 (published snapshot v2026.7, 2026-08-06)

Apaleo scores 77.0 out of 100 on the PMS Power Index. Evidence-backed diagnostic across ten API capabilities. Vendor-neutral. Open to dispute.

Scores by capability

Marketplace coverage

Score: 9 of 9 (Best-in-class). Weight 10%.

Reconciliation note: Both reviewers re-scored to 9 on cross-vendor consistency review. 200+ certified Store apps across the canonical hospitality categories with a published certification process clears anchor_9 as written. The 731-app benchmark from a larger ecosystem is informational only and is not a rubric threshold. [Evidence reconstruction — 2026-08-06] The anchor-9 category-count criterion (8+ categories), previously unevidenced in the ledger, is now supported by a dated evidence row: the Apaleo Store publicly lists nine distinct categories. Combined with the previously-evidenced 200+ integration count and published certification process, all three anchor-9 criteria are now evidenced. Score is unchanged at 9; this note records the completion of the supporting evidence trail.

First scorer rationale: Adjusted to 9 (Best-in-class) on cross-vendor review. Apaleo Store lists 200+ certified third-party applications across the canonical hospitality categories (channel manager, RMS, guest apps, POS) with a documented certification process; this clears anchor_9 as written (150+ certified integrations across 8+ categories with published certification programme). [Rubric version annotation — 2026-08-13] "The anchor-9 formulation quoted above as written (150+ certified integrations across 8+ categories with a published certification programme) is the pre-merge rubric wording. The governing rubric is the merged v2.4, which carries the same three anchor-9 criteria forward unchanged. The reasoning holds under v2.4 and the score is unchanged at 9. The same quoted formulation appears in the secondary rationale on this dimension and is annotated by reference."

Second scorer rationale: Adjusted to 9 on cross-vendor review. 200+ certified Store apps with a documented certification process clears anchor_9 as written; the 731 benchmark is informational, not a rubric threshold. [Rationale reconstruction — 2026-08-08] "Corrected wording: Adjusted to 9 on cross-vendor review. The Apaleo Store is evidenced at over 200 applications with a documented certification process, which clears the anchor-9 criterion of 150+ certified integrations across 8+ categories. The comparator figure cited above is a third-party count of another vendor's marketplace, was expressly ruled out as a non-threshold, and has since moved; it is withdrawn as it serves no scoring purpose. Threshold evidence: c20e30c6-e6f4-424c-be76-5b54979c47c3 (over 200 Store applications, T1) and 8b09a710-0e6e-43b5-ba15-9efeacb225d7 (category structure, T1). Original text above is retained unchanged and the score is unchanged."

  • A published certification process governs listing in the Apaleo Store: applications must complete a documented build, certify and list path including technical review and a pre-certification call before they appear in the marketplace. Mapped in-dimension to evidence the anchor-9 published certification process criterion for Marketplace coverage. https://apaleo.dev/guides/apaleo-store/certify-your-app.html
  • The Apaleo Store features over 200 applications, enabling hotels to extend the core PMS functionality. https://apaleo.com/open-pms
  • The app marketplace is organised into categories such as Channel Manager, Revenue Management, Guest Apps, and Point of Sale. https://apaleo.com/apaleo-store
  • Developer documentation provides dedicated guides for common integration patterns including IBE, POS, Revenue Management, and Finance Management systems. https://apaleo.dev/guides/business-cases/overview.html
  • The UI Integration API allows partner applications to embed their user interface as an iframe directly within the Apaleo PMS at predefined locations, such as a tab on the reservation screen. https://apaleo.dev/guides/apaleo-one/overview.html
  • Apaleo's Distribution API is designed for channel manager integrations, providing subscriptions for availability, rates, and inventory (ARI) updates. https://apaleo.dev/guides/business-cases/channel-integration/overview.html
  • The Apaleo Store category navigation publicly lists nine distinct categories: Operations, Marketing, Restaurant & spa, Guest experience, Meetings & events, Back office & administration, AI-powered, Revenue management, and Distribution. This satisfies the anchor-9 requirement of 8+ categories. The 200+ integration count is corroborated by existing ledger evidence rows. https://store.apaleo.com/

What you can control via the API

Score: 9 of 9 (Best-in-class). Weight 14%.

Reconciliation note: Agreement. Both passes reached the same score independently from the same evidence ledger; row recorded for audit completeness.

First scorer rationale: Apaleo lands at 9 (Best-in-class). The write surface spans the full operational footprint: rates, reservations, accounting, housekeeping and payments are all programmatically accessible via the Core API; granular .manage scopes exist for reservations, rates, folios and room state; PATCH endpoints support partial updates to existing bookings and bulk rate updates; setup APIs enable programmatic creation, modification and deletion of units, unit groups, rate plans and entire properties (true infrastructure-as-code for the hotel); and operational processes are themselves callable, including a dedicated operations.trigger-night-audit scope. The combination of granular write scopes, bulk update endpoints, setup-API depth and callable operational processes is the deepest programmability surface observed to date and matches the Mews benchmark. No material gap observed. [Evidence capture — 2026-08-08] Two anchor-9 criteria previously unmapped on this dimension are now evidenced: room moves, via the documented assign-unit reservation action with its own dedicated scope, and guest profile mutations, via documented guest data submission and guest addition. All six anchor-9 criteria for this dimension are now supported by mapped evidence rows. The score is unchanged at 9.

Second scorer rationale: Independent review: full programmability across booking, finance, inventory and operations via documented public API. Best-in-class confirmed.

  • The Core API provides programmatic access to fundamental hotel operations, including rates, reservations, accounting, housekeeping, and payments. https://apaleo.dev/index.html
  • A granular scope system allows write access to key operational entities, with permissions like `reservations.manage`, `rates.manage`, `folios.manage`, and `operations.change-room-state`. https://apaleo.dev/guides/api/scopes.html
  • Specific write endpoints enable modification of existing bookings via `PATCH /booking/v*/bookings/{id}` and bulk rate updates via `PATCH /rateplan/v*/rates`. https://apaleo.dev/guides/api/rate-limiting.html
  • The platform includes dedicated setup APIs that allow for the programmatic creation, modification, and deletion of units, unit groups, rate plans, and entire properties. https://apaleo.dev/guides/api/scopes.html
  • The API supports triggering operational processes, such as the hotel's night audit, via the `operations.trigger-night-audit` scope. https://apaleo.dev/guides/api/scopes.html
  • Room moves are available as a documented reservation action. PUT /booking/v1/reservation-actions/{id}/assign-unit assigns a specific unit to a reservation in state Confirmed or InHouse, governed by the scopes reservations.assign-unit or reservations.manage. Apaleo's guides document assigning a room, changing the room for an existing reservation, and assigning a different room for specific dates. This is distinct from the operations.change-room-state scope, which governs housekeeping state. https://apaleo.dev/guides/business-cases/guest-journey/pre-stay
  • Guest profile mutation is documented: updated guest data including photo, signature and ID scan is submitted to the guest endpoint, and additional guests can be added to a reservation via API. https://apaleo.dev/guides/business-cases/guest-journey/pre-stay

Real-time updates and webhooks

Score: 6 of 9 (Adequate). Weight 13%.

Reconciliation note: Agreement. Both passes reached the same score independently from the same evidence ledger; row recorded for audit completeness.

First scorer rationale: Apaleo lands at 6 (Solid, with material caveats). The webhook surface is comprehensive and well-engineered: 50+ documented event types across reservation, folio, unit, property and booking; a standard payload structure (topic, type, timestamp, entityId); at-least-once delivery with one-minute retry and explicit guidance for duplicate handling; programmatic subscription management via POST /v1/subscriptions; and a healthcheck handshake on subscription creation. The dimension is capped at 6 because the evidence shows webhooks-only event delivery, with no second-channel streaming or WebSocket surface for low-latency or bidirectional consumption documented in the public guides. This matches the Mews scoring philosophy where comprehensive webhooks alone score Solid; a streaming or push-channel second surface is required for Best-in-class. [Evidence update — 2026-08-08] Retry semantics are updated per documentation revised 2026-08-07: three resend attempts followed by continued delivery attempts for up to 24 hours, superseding the previously recorded one-minute retry interval. The score is unchanged at 6. Anchor 9 is not reached: it requires a full event catalogue, signed payloads, retry with backoff and a replay endpoint. No self-serve programmatic replay mechanism or second delivery channel beyond webhooks is evidenced across the seven-page webhook documentation section. [Evidence update — 2026-08-08] "Delivery authenticity is recorded against the criterion as clarified in v2.4, which states this criterion as verifiable delivery authenticity satisfied by signed payloads or an equivalent documented mechanism. Apaleo documents a URL-appended unique token for subscriber-side verification, HTTPS-only delivery, published outbound IP addresses for allowlisting, and a healthcheck handshake on subscription creation. Cryptographic payload signing is not documented; the v2.4 clarification records that payload signing remains the strongest implementation and continues to contribute at anchor 9. The score is unchanged at 6."

Second scorer rationale: Independent review: webhook topics documented across core entities but no exactly-once or replay guarantees published. Solid confirmed.

  • A Webhook API allows applications to subscribe to events, which is the recommended method for receiving updates instead of polling. https://apaleo.dev/guides/webhook/overview.html
  • A comprehensive list of over 50 event types is documented, covering topics such as `reservation`, `folio`, `unit`, `property`, and `booking`. https://apaleo.dev/guides/webhook/configuration.html
  • Webhook payloads follow a standard structure, containing the topic, type, timestamp, and the `entityId` of the object that changed. https://apaleo.dev/guides/webhook/webhooks-payload.html
  • The webhook service provides an at-least-once delivery guarantee. It will retry sending a notification every minute upon failure, and developers are advised to handle potential duplicate events. https://apaleo.dev/guides/webhook/best-practices.html
  • Subscription to webhooks is managed programmatically by making a `POST` request to the `/v1/subscriptions` endpoint. https://apaleo.dev/guides/webhook/configuration.html
  • When subscribing to a webhook, Apaleo sends an initial `healthcheck` event to the endpoint, which must return a 2xx status code for the subscription to be created. https://apaleo.dev/guides/webhook/webhooks-payload.html
  • Webhook delivery guarantees, per the Guarantees and error handling section: notification delivered within 60 seconds; at-least-once delivery with deduplication by ID field; on delivery failure the event is resent up to 3 times, and if still unsuccessful delivery attempts continue for up to 24 hours; events are not ordered and timestamps are provided for ordering; optional JWT token on the callback URL for authenticity verification. https://apaleo.dev/guides/webhook/best-practices.html
  • Delivery authenticity is documented through an optional but recommended unique token appended to the subscriber's callback URL, illustrated with a JWT, allowing the subscriber to authenticate and certify that a received notification is a valid Apaleo webhook and to identify the intended client from a single base URL. Delivery is HTTPS-only to the subscriber endpoint, and Apaleo publishes its three outbound IP addresses for allowlisting. Subscription creation requires a healthcheck event returning a 2xx response before the subscription is created. https://apaleo.dev/guides/webhook/best-practices.html

Readiness for AI agents

Score: 6 of 9 (Adequate). Weight 12%.

Reconciliation note: Agreement. Both passes reached the same score independently from the same evidence ledger; row recorded for audit completeness.

First scorer rationale: Apaleo lands at 6 (Solid, with material caveats) and is materially ahead of cloud-native peers on AI readiness. Concrete evidence: an MCP server exposing ~230 tools across booking, finance, inventory and operations, a documented Claude plugin, an LLM-friendly documentation surface (llms.txt sitemap plus raw .md endpoints on every page), and showcased agentic apps in the Apaleo Store (Sales Agent, Email Agent, Migration Agent). The latent AI surface area is high. Two caveats hold this below best-in-class: (1) the MCP server is in Closed Alpha rather than GA, so third parties cannot rely on it for production agent integrations yet; (2) public documentation contains no native primitives for embeddings or vector retrieval, leaving agent memory and semantic search as integrator responsibilities. The combination of an exposed agent tool surface plus LLM-native docs nonetheless puts Apaleo decisively above Limited. [Evidence update — 2026-08-08] The MCP server status is updated from closed alpha to generally available, per the first-party production listing on the Apaleo Store. This resolves the previously flagged anchor-6 concern that a closed-alpha agent tool service may fall below the beta or limited-release threshold. The score is unchanged at 6. Anchor 9 is not reached: it requires a semantic search or embeddings endpoint in addition to a production agent tool service, and no embeddings or semantic-retrieval capability is evidenced. This is consistent with the treatment of comparable vendors, whose publicly available agent surfaces are scored 6 on the same missing-embeddings criterion. [Rationale correction — 2026-08-09] "Caveat (1) above is withdrawn as superseded. The Apaleo MCP Server is generally available as a first-party production integration on the Apaleo Store, included in the standard Apaleo subscription, with no alpha, beta or waitlist restriction stated, evidenced at row f0c28f30 captured 2026-08-08. The statement that third parties cannot rely on it for production agent integrations no longer reflects the evidence and is withdrawn. The score is unchanged at 6. Anchor 9 is not reached for one reason only: it requires a semantic search or embeddings endpoint in addition to a production agent tool service, and Apaleo's own public documentation records that no native embeddings or vector retrieval capability is provided, evidenced at row 16719ea8. This treatment is consistent across comparable vendors, none of which evidences a semantic search or embeddings surface."

Second scorer rationale: Independent review: MCP server (Closed Alpha) and llms.txt push above Limited; lack of GA prevents best-in-class. Solid confirmed. [Rationale correction — 2026-08-13] "Two statements above are withdrawn as superseded. The characterisation of the MCP server as Closed Alpha is withdrawn: the Apaleo MCP Server is generally available as a first-party production integration on the Apaleo Store, included in the standard Apaleo subscription, with no alpha, beta or waitlist restriction stated, evidenced at row f0c28f30. The statement that the lack of general availability prevents best-in-class is withdrawn with it. The score is unchanged at 6. Anchor 9 is not reached for one reason only: the absence of a semantic search or embeddings endpoint, evidenced at row 16719ea8."

  • The developer documentation is designed to be LLM-friendly, providing a full sitemap in `llms.txt` format and offering raw markdown (`.md`) versions of all content pages. https://apaleo.dev/index.html
  • The ecosystem promotes agentic AI integrations, with showcased examples including a Sales Agent, Email Agent, and Migration Agent. https://apaleo.com/apaleo-store
  • The public developer documentation does not contain information about native support for data embeddings or vector database functionalities. https://apaleo.dev/guides/ai/overview.html
  • The MCP server, currently in Closed Alpha, exposes approximately 230 tools, allowing AI agents to interact with booking, finance, inventory, and operations APIs via natural language. https://apaleo.dev/guides/ai/overview.html
  • Apaleo provides explicit AI integration capabilities, including a Claude plugin and a Multi-purpose Cooperative Protocol (MCP) server for connecting LLMs. https://apaleo.dev/guides/ai/overview.html
  • The Apaleo MCP Server is listed as the official first-party Model Context Protocol integration on the Apaleo Store, included in the standard Apaleo subscription at no additional cost, using OAuth 2.0 with scope-based permissions and honouring existing user roles. Compatible with Claude, ChatGPT, n8n and any MCP client. No alpha, beta or waitlist restriction is stated. https://store.apaleo.com/apps/apaleo-mcp-server

Data model and multi-property design

Score: 6 of 9 (Adequate). Weight 10%.

Reconciliation note: Agreement. Both passes reached the same score independently from the same evidence ledger; row recorded for audit completeness.

First scorer rationale: Apaleo lands at 6 (Solid, with material caveats). Strengths: multi-property is native (single login, unified data across the chain), the financial model is built on real-time double-entry bookkeeping with configurable accounting schemes and taxes (a meaningful step above flat-folio peers), reservation structures distinguish individual reservations, multi-reservation bookings, groups and blocks as first-class types, and inventory supports beds, long stays, meetings and parking alongside traditional rooms. The principal gap that prevents a 9: the public API overview and data model documentation make no reference to custom fields or metadata extension on core entities. Without first-class extensibility, partners must work around the canonical schema, which is a defensible weakness versus best-in-class peers and the main reason this sits at Solid rather than Best-in-class. [Evidence capture — 2026-08-09] Two anchor-6 criteria previously unevidenced on this dimension are now supported by mapped evidence rows. Shared guest profile across properties: evidenced. Apaleo publishes a dedicated Profile API at the platform layer, described as building and deduplicating guest profiles, and the multi-property architecture already evidenced at row db4f5a6f records a single login with a unified view of data across all properties in a chain. Guest profile data is therefore held at chain level rather than per property. Standard reporting API: evidenced. Finance reporting and export are documented as platform capabilities, and the API enforces a separate pagination model for analytical data, distinct from that used for business data, establishing an analytical surface. All three anchor-6 criteria for this dimension are now supported by mapped evidence rows: shared guest profile, multi-property hierarchy, and a standard reporting API. The score is unchanged at 6. Anchor 9 is not reached: it requires a unified guest profile with custom attribute support and a real-time reporting API with portfolio-level aggregation. Custom field or metadata support on core entities is not evidenced, recorded at row 9786b0b2, and portfolio-level aggregation on the reporting surface is not evidenced.

Second scorer rationale: Independent review: native multi-property and real-time double-entry accounting; absence of documented custom-field extension prevents best-in-class. Solid confirmed.

  • The platform is designed with a multi-property architecture, allowing a single login and a unified view of data across all properties in a chain. https://apaleo.com/open-pms
  • The financial data model is built on real-time, double-entry bookkeeping principles and allows for customization of accounting schemes and taxes. https://apaleo.com/open-pms
  • The data model distinguishes between complex reservation structures such as individual reservations, multi-reservation bookings, groups, and blocks. https://apaleo.dev/guides/webhook/configuration.html
  • The inventory model supports various types of sellable units beyond traditional rooms, including long stays, beds, meetings, and parking. https://apaleo.com/open-pms
  • The API overview and data model documentation make no reference to custom field or metadata support on core entities. https://apaleo.dev/guides/api/overview.html
  • Apaleo publishes a dedicated Profile API as one of its platform APIs, described as building up guest profiles and deduplicating them. The Profile API is a platform-level API listed alongside the Identity, Webhooks, Inventory, Rate Plan, Settings and UI Integration APIs, rather than a per-property facility. Combined with the multi-property architecture evidenced at row db4f5a6f, which records a single login and unified view of data across all properties in a chain, guest profile data is held and deduplicated at the chain level rather than per property. https://apaleo.com/open-apis
  • Apaleo documents finance reporting and export as a platform capability, alongside real-time double-entry bookkeeping and configurable accounting schemes and taxes. The API separately enforces a distinct pagination model for analytical data, using a cursor and limit model with a maximum of 500 records per page as against a page and size model for business data, evidenced at row ac9bcb50, establishing a separate analytical data surface. https://apaleo.com/open-pms

Developer tooling and sandbox

Score: 6 of 9 (Adequate). Weight 10%.

Reconciliation note: MAD 3 at threshold. Secondary weighted the self-serve developer account, resettable sandbox and GitHub-backed changelog as best-in-class. On reconciliation the v2.0 rubric requires first-party language SDKs for a Best-in-class score; Apaleo currently ships none. Primary score holds. [Rubric version annotation — 2026-08-13] "The reasoning above cites the v2.0 rubric as governing. The governing rubric is the merged v2.4. The first-party language SDK requirement moved to anchor 9 only at v2.4; Apaleo was already placed at anchor 6, so the requirement does not bear on the outcome. The reconciled outcome is unchanged."

First scorer rationale: Apaleo lands at 6 (Solid, with material caveats). Strengths versus cloud-native peers: self-serve free developer account with a sandbox containing resettable sample data (no human gating to start building), interactive "Try it out" execution embedded in the Swagger UI for every endpoint, public community forum plus a dedicated api@apaleo.com support channel, and a public changelog backed by a GitHub announcements repository for machine-readable subscription. Two structural gaps prevent a 9: (1) no official language-specific SDKs are referenced in the API documentation, so integrators write raw HTTP clients (the same gap observed at Mews); (2) onboarding still depends on certification review before store listing, although the developer sandbox itself is fully self-serve. The self-serve developer portal is a clear advantage over gated-only peers and the principal reason this scores Solid.

Second scorer rationale: Independent review: self-serve free developer account with resettable sandbox, interactive Try-it-out, public changelog with GitHub feed and dedicated support channel. Secondary lands one notch above primary.

Uptime and operational discipline

Score: 6 of 9 (Adequate). Weight 9%.

Reconciliation note: Agreement. Both passes reached the same score independently from the same evidence ledger; row recorded for audit completeness.

First scorer rationale: Apaleo lands at 6 (Solid, with material caveats). Strengths: rate limits are published with concrete numbers (3500 requests/minute on live accounts, lower on developer accounts), with HTTP 429 responses carrying a Retry-After header for graceful backoff; pagination is standardised with separate models for business data (page/size, max 200) and analytical data (cursor/limit, max 500); path-based versioning explicitly distinguishes a stable v1 from an unstable v0-nsfw beta surface, giving integrators a clear stability contract; a public status page (status.apaleo.com) publishes current and historical uptime with alert subscription; and standard HTTP status codes with documented OAuth error responses round out the error contract. The cap at 6 reflects a single but material gap: public documentation references performance targets but does not publish a formal SLA with binding uptime commitments, which is the floor for Best-in-class on this dimension. Note: Apaleo does not publish a formal uptime SLA percentage; the automated status page with historical data satisfies anchor_6's monitoring criterion regardless. [Evidence correction — 2026-08-08] A published uptime SLA has been located in Apaleo's Terms & Conditions (§ 4.2): 99.5% average monthly availability, excluding scheduled maintenance, with seven days' advance notice of maintenance windows. This satisfies the anchor-6 criterion of a published uptime SLA of 99.5% or higher. The prior evidence row asserting no formal SLA was assessed against developer documentation only and did not include commercial terms; it is superseded. The score is unchanged at 6. Anchor 9 is not reached: it requires an uptime SLA of 99.9% or higher with API-specific tracking, and the published commitment is 99.5% platform-wide. [Rationale correction — 2026-08-09] "Two statements above are withdrawn as superseded. The statements that Apaleo does not publish a formal SLA with binding uptime commitments, and does not publish a formal uptime SLA percentage, are incorrect. Apaleo publishes an uptime commitment of 99.5% average monthly availability in its Terms and Conditions §4.2, effective 01/06/2026, excluding scheduled maintenance of no more than one hour per week, with seven days' advance notice of maintenance windows under §4.3. This is evidenced at row 307fdcdc, captured 2026-08-08. The anchor-6 criterion of a published uptime SLA of 99.5% or higher is met. The score is unchanged at 6. Anchor 9 is not reached: it requires an uptime SLA of 99.9% or higher with API-specific tracking; the published commitment is 99.5% and platform-wide."

Second scorer rationale: Independent review: public status page maintained but no published SLA. Solid confirmed. [Rationale correction — 2026-08-13] "The statement above that no SLA is published is withdrawn as superseded. Apaleo publishes an uptime commitment of 99.5% average monthly availability in its Terms and Conditions §4.2, excluding scheduled maintenance, evidenced at row 307fdcdc. The anchor-6 criterion of a published uptime SLA of 99.5% or higher is met. The score is unchanged at 6. Anchor 9 is not reached: it requires 99.9% or higher with API-specific tracking."

  • API rate limits are documented in detail, with separate thresholds for live (3500 requests/minute) and development accounts. Exceeding the limit returns an HTTP 429 response with a `Retry-After` header. https://apaleo.dev/guides/api/rate-limiting.html
  • APIs enforce standard pagination, using a page/size model for business data (max 200 per page) and a cursor/limit model for analytical data (max 500 per page). https://apaleo.dev/guides/api/pagination.html
  • The API uses path-based versioning, distinguishing between a stable `v1` and an unstable `v0-nsfw` (Not Safe For Work) version used for beta features. https://apaleo.dev/guides/api/versioning.html
  • A public status page at status.apaleo.com displays current system status, historical uptime, and planned maintenance, with options to subscribe to alerts. https://apaleo.dev/index.html
  • The API employs standard HTTP status codes to indicate success or failure, and documentation specifies response details for OAuth errors. https://apaleo.dev/guides/api/errors.html
  • Public documentation references performance targets but does not publish a formal SLA with binding uptime commitments. https://apaleo.com/open-apis
  • Apaleo publishes a formal uptime commitment in its Terms & Conditions (§ 4.2, valid from 01/06/2026): the full version of the Platform will be available for an average of 99.5% of the time, determined monthly, excluding scheduled maintenance of no more than one hour per week. § 4.3 commits to announcing scheduled maintenance at least seven days in advance. § 4.4 defines excluded downtime categories. https://apaleo.com/terms-conditions

Security, authentication, and compliance

Score: 6 of 9 (Adequate). Weight 8%.

Reconciliation note: [Superseded — 2026-08-05] The narrative immediately below records the position before the 2026-08-05 evidence submission and is retained for audit. The operative rationale is the 2026-08-05 block, which reconciles this dimension at 6. Corrected record. The prior reconciliation stated agreement at 9; the live rows disagree (primary 6, secondary 9). Reconciled to 3 per the governance_security anchor_6 gate: anchor 6 requires SOC 2 Type II or ISO 27001 plus a locatable GDPR DPA. The evidence ledger contains neither; the only certification present is PCI DSS, which the anchor_6 gate does not accept as a substitute, and the secondary rationale asserted SOC 2 / ISO 27001 / GDPR DPA that do not appear in its cited evidence. Apaleo holds the strongest OAuth and granular-scope implementation in the cohort, which makes it the strongest 3, but authorisation strength does not clear the certification gate that decides this dimension. Consistent with cloudbeds and stayntouch, scored 3 on the same missing-certification pattern. [Score update — 2026-08-05] "Governance & Security moves from 3 to 6. The governance ledger now contains evidence for a publicly locatable GDPR Data Processing Agreement and a verified SOC 2 Type II attestation. OAuth 2.0 with 40+ granular scopes was already evidenced. The previous reconciliation to 3 reflected the absence of these evidence records at the time of review. With these additions, the anchor requirements for score 6 are satisfied. Score does not reach 9 because ISO 27001, published penetration-testing cadence and documented RBAC remain unevidenced."

First scorer rationale: The OAuth implementation alone is genuinely best-in-class for the authorisation half of this dimension: OAuth 2.0 with full OpenID Connect, a public OIDC discovery endpoint, and over 40 granular scopes separating .read from .manage per entity, alongside a mandatory app-side certification programme that audits OAuth flow correctness, scope minimisation and error handling. The certification half does not clear anchor_9, however. Anchor_9 requires OAuth 2.0 with granular scopes PLUS SOC 2 Type II PLUS ISO 27001 PLUS a published GDPR DPA PLUS a published penetration-test cadence. PCI DSS with annual on-site audits and a downloadable AOC is evidenced, but PCI DSS is neither SOC 2 nor ISO 27001, and no GDPR DPA or published pentest cadence appears on the developer-trust surface. Anchor_6 is the closest fit: OAuth 2.0 with scoped permissions is met outright; the SOC 2 Type II or ISO 27001 plus GDPR DPA requirement is not strictly met by PCI DSS alone, but the granular-scope OAuth implementation is strong enough to retain Adequate rather than drop to Limited. Flagged pending further certification evidence. [Rationale correction — 2026-08-13] "The statement above that no GDPR Data Processing Agreement appears on the developer-trust surface, and that the only certification present is PCI DSS, are both withdrawn. A publicly locatable GDPR Data Processing Agreement is evidenced at apaleo.com/dpa, and SOC 2 Type II certification is evidenced, the Type II designation, auditor, audit period and opinion having been verified against the independent auditor's report. Both anchor-6 certification legs are satisfied alongside OAuth 2.0 with granular scopes, and the dimension was reconciled from 3 to 6 on 2026-08-05. Anchor 9 is not reached: it requires ISO 27001 alongside SOC 2, a published penetration-test cadence and documented role-based API access controls, none of which is evidenced. Score unchanged at 6."

Second scorer rationale: Independent review: SOC 2, ISO 27001, GDPR DPA, OAuth 2.0 with full scope model and Store-level security review. Best-in-class confirmed. [Annotation 2026-08-06] The ISO 27001 assertion in this secondary pass is not supported by any evidence row and did not carry into the reconciled score. SOC 2 Type II and the GDPR DPA are evidenced; ISO 27001 is not. Retained for audit; superseded by the reconciliation.

  • API authentication relies on the OAuth 2.0 protocol, with support for OpenID Connect (OIDC) for user identity verification and a public OIDC discovery endpoint. https://apaleo.dev/guides/oauth-connection/oauth-openid.html
  • API access is governed by over 40 granular OAuth scopes that distinguish between read (`.read`) and write (`.manage`) permissions for entities like `reservations` and `folios`. https://apaleo.dev/guides/api/scopes.html
  • Apaleo is PCI DSS compliant, undergoes annual on-site audits, and makes its Attestation of Compliance (AOC) available for download. https://apaleo.com/pci
  • A mandatory certification programme for all store apps ensures integrations correctly implement security practices, including OAuth flows, scope minimisation, and error handling. https://apaleo.dev/guides/apaleo-store/certify-your-app.html
  • Security best practices require the use of HTTPS for all API and authentication requests and recommend using the `state` parameter in OAuth flows to prevent CSRF attacks. https://apaleo.dev/guides/oauth-connection/best-practices.html
  • Apaleo publishes a GDPR Data Processing Agreement at apaleo.com/dpa, linking a signed DPA with technical and organisational measures. https://apaleo.com/dpa
  • Apaleo publicly states that it is SOC 2 compliant. The SOC 2 Type II designation, auditor (Sensiba LLP), audit period (10 September 2024 to 30 September 2025), scope (Security, Availability, Confidentiality), and unqualified opinion were independently verified from the auditor's report cover page supplied by the vendor on 2026-08-05. The confidential report itself is not stored or referenced as a public evidence source. https://apaleo.com/

Partner programme and references

Score: 6 of 9 (Adequate). Weight 7%.

Reconciliation note: Agreement. Both passes reached the same score independently from the same evidence ledger; row recorded for audit completeness.

First scorer rationale: Apaleo lands at 6 (Solid, with material caveats). The ecosystem clears several defensible bars: the Apaleo Store lists 200+ certified third-party apps across the canonical hospitality categories; the certification programme is formal and documented (technical reviews, pre-certification calls, mandatory security implementation); a Partner Success Kit supports partners go-to-market; and customer references include credible cloud-native operators (citizenM, Limehome, Valk Exclusief) with explicit API-led use cases. Two factors prevent a 9: (1) integration breadth (200+) is materially below the best-in-class Mews benchmark (731 independently verified); (2) public marketing and developer documentation make no reference to a hosted developer conference or annual partner summit, which is the convening signal best-in-class ecosystems use to compound network effects. The ecosystem is genuine and growing but has not yet reached the scale or convening cadence of the category leader. Note: a developer forum or Slack community channel is not confirmed in current evidence; the Apaleo Store, certification programme and Partner Success Kit satisfy anchor_6's other criteria regardless. [Rationale correction — 2026-08-09] "Two reasons stated above for withholding best-in-class are withdrawn. First, the comparator figure of 731 is withdrawn: it is a third-party count of another vendor's marketplace, was expressly ruled out as a non-threshold and withdrawn from Marketplace coverage on 2026-08-08, and has no evidence row on this dimension. Second, the absence of a hosted developer conference or partner summit is not a criterion at any anchor of this dimension and is withdrawn as a reason. The score is unchanged at 6. The operative position is stated against the anchor-9 criteria that govern this dimension: a tiered partner programme with published economics, an active developer community, a reference customer programme, and a documented dedicated partner success resource. Published partner economics are not evidenced. An active developer forum or community channel is not evidenced, as noted in the rationale above. Anchor 9 is therefore not reached. Anchor-6 coverage is recorded as partial: the publicly searchable partner directory is evidenced, the partner programme is evidenced as formal and documented but published tiers are not evidenced, and an active community is not evidenced. This partial coverage is disclosed in accordance with the v2.4 criterion-coverage clarification; the score is unchanged under the Evidence Reconstruction Principle."

Second scorer rationale: Independent review: 200+ Store apps, formal certification, named cloud-native references; breadth gap vs. Mews prevents best-in-class. Solid confirmed.

  • Apaleo operates the Apaleo Store, a central marketplace where hotel customers can discover and connect more than 200 certified third-party applications. https://apaleo.com/apaleo-store
  • A formal partner programme is in place with a documented process for building, certifying, and listing applications, which includes technical reviews and pre-certification calls. https://apaleo.dev/guides/apaleo-store/certify-your-app.html
  • The company publishes customer success stories from hotel brands such as citizenM, Limehome, and Valk Exclusief, often highlighting their use of the platform's APIs. https://apaleo.com/open-pms
  • A 'Partner Success Kit' is available to technology partners, containing guidelines and collateral to support their go-to-market efforts. https://apaleo.com/apaleo-store
  • Developer documentation and public marketing pages make no reference to hosted developer conferences or partner summit events. https://apaleo.com

Documentation and changelog discipline

Score: 9 of 9 (Best-in-class). Weight 7%.

Reconciliation note: Agreement. Both passes reached the same score independently from the same evidence ledger; row recorded for audit completeness. [Evidence reconstruction — 2026-08-06] Reconstruction under the v2.4 criterion-coverage clarification. Five of the six anchor-9 criteria are now supported by mapped evidence rows: complete endpoint coverage, versioning with deprecation policy, changelog with dates, complete error reference, and recency. The sixth criterion, code examples in two or more languages, is not met by first-party documentation: examples are provided in cURL with JSON payloads, and Apaleo's own documentation directs integrators to generate typed clients from the published OpenAPI specification using third-party generators rather than supplying first-party language examples. This criterion could not be located and is disclosed here in accordance with the v2.4 clarification. The published score is unchanged at 9 under the Evidence Reconstruction Principle; the unmet criterion is recorded for assessment at the next scheduled review.

First scorer rationale: Apaleo lands at 9 (Best-in-class). Every documentation-quality criterion in the v2.0 rubric is met: all APIs are described in OpenAPI/Swagger with generated interactive reference; the getting-started guide branches by integration type (public Store app vs. private single-hotel integration); OAuth 2.0 documentation specifies both supported grant types with explicit guidance on which to use; webhook documentation includes a complete table of every event topic and type with triggering action; the changelog documents deprecations with named fields, removal dates and several months of advance notice; a reverse-chronological public changelog is maintained continuously; and the documentation is explicitly structured for LLM consumption via llms.txt and raw .md access on every page. AI-native documentation surfaces are matched only by Mews among the vendors observed to date. No material gap observed. [Rubric version annotation — 2026-08-13] "The reasoning above cites the v2.0 rubric as governing. The governing rubric is the merged v2.4. The documentation-quality criteria relied on are carried forward unchanged into v2.4 and the reasoning holds under it. The score is unchanged at 9."

Second scorer rationale: Independent review: OpenAPI for every endpoint, branching getting-started, webhook topic table, deprecation policy, LLM-native llms.txt and raw .md surfaces. Best-in-class confirmed.

  • Webhook documentation includes a detailed table of every event topic and type, along with a description of the triggering action. https://apaleo.dev/guides/webhook/configuration.html
  • The changelog documents API deprecations, specifying which fields or endpoints are affected and providing a clear removal date, giving developers several months of advance notice. https://apaleo.com/changelog
  • A public, reverse-chronological changelog is maintained, which announces new features, API changes, and deprecations. https://apaleo.com/changelog
  • The documentation is explicitly structured for consumption by LLMs, providing a sitemap via 'llms.txt' and raw markdown access to pages. https://apaleo.dev/index.html
  • All APIs are described using the OpenAPI Specification (Swagger), which generates interactive documentation listing all endpoints, methods, and data models. https://apaleo.dev/guides/api/overview.html
  • The documentation provides a 'Getting Started' guide that directs developers based on their project type: a public app for the Apaleo Store or a private integration for a single hotel. https://apaleo.dev/index.html
  • Authentication documentation details the supported OAuth 2.0 grant types (Authorization Code and Client Credentials) and provides guidance on which to choose. https://apaleo.dev/guides/oauth-connection/which-oauth.html
  • A dedicated error reference documents the HTTP status codes returned by every API across five status categories, supported by a separate troubleshooting guide that routes by status code. https://apaleo.dev/guides/api/errors.html
  • Developer documentation pages carry published revision dates within the preceding three months, satisfying the anchor-9 recency criterion at the date of capture. https://apaleo.dev/guides/api/overview.html

Scores are published only where documented evidence exists. Corrections and disputes are recorded in the public changelog. The scoring rubric is published in full in the methodology.

This provider is listed in the HotelLogic marketplace →

Rank 2 of 17 scored vendors on the PMS Power Index ladder.