Cloudbeds · PMS Power Index

Composite score: 73.3 / 100 (published snapshot v2026.6, 2026-08-13)

Cloudbeds scores 73.3 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 independently assigned the same score. No disagreement required reconciliation; the agreed score has been recorded. [2026-08-09] Corrected from 6 to 9 on both reviewer scores following the dated score correction recorded in the rationales. A count is publicly enumerable via the integrations sitemap and clears the anchor-9 threshold; the count-agnostic reasoning is withdrawn. [Reconciliation brought to current position — 2026-08-13] "The current score is 9. Operative reason: a publicly enumerable catalogue via integrations-sitemap.xml, exceeding 150 on a deduplicated basis across well over eight categories, with the published certification process separately evidenced. No precise count is recorded. The text above records the superseded position and is retained unchanged for audit."

First scorer rationale: Marketplace in-app listing plus public integrations catalogue plus eight named blueprint categories evidence broad coverage. No authoritative live-partner count is published on the developer surface, capping the dimension at adequate rather than best-in-class. [Score correction — 2026-08-09] "Integration Breadth moves from 6 to 9. The anchor is count-based at every band, and the record contained no count on either side of any threshold. The secondary rationale's reference to count-agnostic scoring is withdrawn: the anchor text does not authorise it. A count is publicly enumerable. Cloudbeds publishes an XML sitemap of individual integration pages, linked from robots.txt, which exceeds 150 integrations on a deduplicated basis across well in excess of eight categories. No precise figure is recorded, in accordance with the treatment adopted across the vendor set on 2026-08-08: where a count is used to clear a threshold, the threshold is evidenced rather than the figure. The sitemap contains localised duplicates and a small number of pilot records, so any raw URL count overstates the catalogue. The published certification process criterion is separately evidenced. All three anchor-9 criteria are met. The score is 9."

Second scorer rationale: Marketplace presence with categorical coverage matches Apaleo posture. Count-agnostic scoring (consistent with Mews and Apaleo) lands at 6. [Score correction — 2026-08-09] "Integration Breadth moves from 6 to 9. The anchor is count-based at every band, and the record contained no count on either side of any threshold. The secondary rationale's reference to count-agnostic scoring is withdrawn: the anchor text does not authorise it. A count is publicly enumerable. Cloudbeds publishes an XML sitemap of individual integration pages, linked from robots.txt, which exceeds 150 integrations on a deduplicated basis across well in excess of eight categories. No precise figure is recorded, in accordance with the treatment adopted across the vendor set on 2026-08-08: where a count is used to clear a threshold, the threshold is evidenced rather than the figure. The sitemap contains localised duplicates and a small number of pilot records, so any raw URL count overstates the catalogue. The published certification process criterion is separately evidenced. All three anchor-9 criteria are met. The score is 9."

  • Cloudbeds maintains a public Integrations webpage at cloudbeds.com/integrations as the canonical partner catalogue. https://www.cloudbeds.com/integrations/
  • A precise count of live Marketplace partners is not stated on the developer documentation surface reviewed; presence is implied by the public Integrations webpage rather than declared as an authoritative figure. https://www.cloudbeds.com/integrations/
  • Cloudbeds operates an in-app Marketplace listing of partner integrations as the "one-stop shop" for partner apps. https://developers.cloudbeds.com/docs/partner-marketing-requirements
  • Cloudbeds publishes integration blueprints by category (Accounting, POS, Door Locks, Housekeeping, Event Management, RMS, CRM, Booking Engine) covering distinct ISV verticals. https://developers.cloudbeds.com/docs/about-cloudbeds-api
  • Partner certification requires app-detail content, marketing material, and a Limited Release with five piloting properties before Marketplace visibility. https://developers.cloudbeds.com/docs/integration-guide
  • Cloudbeds publishes an XML sitemap enumerating individual integration detail pages, linked from robots.txt and publicly retrievable. The catalogue exceeds 150 integrations on a deduplicated basis and spans well in excess of eight categories, including accounting, point of sale, door locks and access control, housekeeping and operations, revenue management, CRM and guest engagement, booking engines, payments, call accounting, spa and wellness, events and groups, reputation management, wifi and networking, ID scanning, upselling, business intelligence and reporting, channel management, distribution and GDS, and self-service kiosks. The sitemap contains localised duplicates at /es/ and /pt-br/ paths, and a small number of pilot and coming-soon records; a precise count is therefore not recorded. The threshold, not the count, is evidenced. https://www.cloudbeds.com/integrations-sitemap.xml

What you can control via the API

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

Reconciliation note: Both reviewers independently assigned the same score. No disagreement required reconciliation; the agreed score has been recorded. [2026-08-09] Corrected from 6 to 9 on both reviewer scores following the dated score correction recorded in the rationales. Housekeeping write access is documented, and the commercial-gating reason is withdrawn as without authority under methodology §11. [Reconciliation brought to current position — 2026-08-13] "The current score is 9. Operative reason: all six anchor-9 criteria are evidenced, including postHousekeepingStatus for housekeeping writes and write:guest with postGuest and putGuest for guest profile mutation. The add-on gating reason is withdrawn as excluded by methodology §11. The text above records the superseded position and is retained unchanged for audit."

First scorer rationale: Reservations, folios, POS charges, room assignment, rate plans, and accounting transactions are programmatically write-targetable. Structural limits (secondary folios not writable, door locks gated, no night-audit mutation) plus add-on gating on Accounting and Groups cap this below best-in-class. [Score correction — 2026-08-09] "Operational Programmability moves from 6 to 9. Two corrections apply. First, a factual error. The rationale above records housekeeping as read-only. Cloudbeds' own developer documentation, at the page cited in the superseded evidence row, documents postHousekeepingStatus as the operation to change housekeeping status, together with postHousekeeper, putHousekeeper and postHousekeepingAssignment, and a dedicated housekeeping scope. Housekeeping write access is available and documented. The anchor-6 condition, which requires that rate plan mutation or housekeeping updates be absent, does not hold: rate plan mutation is separately evidenced and housekeeping updates are documented. Second, a scoring reason without authority. The rationale caps this dimension on add-on gating for Accounting and Groups modules. Section 11 of the published methodology states that v2.0 does not score endpoint gating by commercial tier, partner agreement friction, or per-call versus included pricing. The self-serve enablement rule published on 2026-08-09 is expressly non-retrospective, effective from the next scheduled review, and does not apply to this assessment. The gating reason is therefore withdrawn as without authority under the methodology in force. All six anchor-9 criteria are evidenced: reservation lifecycle, folio mutation, rate management, room moves, housekeeping status writes, and guest profile mutation via write:guest with postGuest and putGuest. The score is 9." [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 criteria and clauses relied on are carried forward unchanged into v2.4 and the reasoning holds under it. The score is unchanged."

Second scorer rationale: Strong write surface across core PMS objects. Add-on gating and the secondary-folio limitation prevent a 9; 6 is correct. [Score correction — 2026-08-09] "Operational Programmability moves from 6 to 9. Two corrections apply. First, a factual error. The rationale above records housekeeping as read-only. Cloudbeds' own developer documentation, at the page cited in the superseded evidence row, documents postHousekeepingStatus as the operation to change housekeeping status, together with postHousekeeper, putHousekeeper and postHousekeepingAssignment, and a dedicated housekeeping scope. Housekeeping write access is available and documented. The anchor-6 condition, which requires that rate plan mutation or housekeeping updates be absent, does not hold: rate plan mutation is separately evidenced and housekeeping updates are documented. Second, a scoring reason without authority. The rationale caps this dimension on add-on gating for Accounting and Groups modules. Section 11 of the published methodology states that v2.0 does not score endpoint gating by commercial tier, partner agreement friction, or per-call versus included pricing. The self-serve enablement rule published on 2026-08-09 is expressly non-retrospective, effective from the next scheduled review, and does not apply to this assessment. The gating reason is therefore withdrawn as without authority under the methodology in force. All six anchor-9 criteria are evidenced: reservation lifecycle, folio mutation, rate management, room moves, housekeeping status writes, and guest profile mutation via write:guest with postGuest and putGuest. The score is 9." [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 criteria and clauses relied on are carried forward unchanged into v2.4 and the reasoning holds under it. The score is unchanged."

  • Group business is programmatically addressable via the Groups and Events module (Profile, Event, Allotment Block hierarchy), but the module is an optional add-on requiring property-level enablement. https://developers.cloudbeds.com/docs/event-management
  • Accounting transactions are fully addressable via the new Accounting API (transactions, taxes/fees, sources, adjustments), reachable by partners after activation by integrations@cloudbeds.com. https://developers.cloudbeds.com/docs/accounting
  • Housekeeping room status can be read via getRoomTypes, getRooms, and reservation endpoints; Cloudbeds describes its native housekeeping as "basic" and positions third-party integrations as complementary. https://developers.cloudbeds.com/docs/housekeeping-staff-management
  • Night audit completion is exposed as a webhook (nightAudit/completed) rather than as a triggerable mutation; programmatic initiation of night audit is not documented. https://developers.cloudbeds.com/docs/accounting
  • Door-lock key issuance via API is documented but the UI surface is currently in limited release, requiring email enablement via integrations@cloudbeds.com per property. https://developers.cloudbeds.com/docs/doorlocks-via-api
  • Charges can only be posted to the primary guest folio on a reservation; secondary guest folios are not programmatically write-targetable. https://developers.cloudbeds.com/docs/point-of-sale
  • POST and PUT endpoints exist for reservations, folios (POST charges via POS), folio item adjustments, void adjustments, room assignment, rate plans, and house-account transactions. https://developers.cloudbeds.com/docs/point-of-sale
  • Cloudbeds API scopes follow a read:<resource> and write:<resource> convention. write:guest is documented for guest profile mutation, with postGuest to create and putGuest to update an existing guest profile including contact information, preferences and document details. write:reservation is documented for reservation mutation. The same scope list documents write:housekeeping and write:rate. https://developers.cloudbeds.com/reference/put_putguest-2
  • Cloudbeds documents housekeeping status as writable via the API: "When the room has been cleaned use postHousekeepingStatus to change the status in Cloudbeds." The same page documents getHousekeepingStatus for reads, postHousekeeper and putHousekeeper for housekeeper records, and postHousekeepingAssignment to assign rooms to a housekeeper. The API changelog records that a dedicated housekeeping scope is required for housekeeping-related calls. https://developers.cloudbeds.com/docs/housekeeping-staff-management

Real-time updates and webhooks

Score: 3 of 9 (Limited). Weight 13%.

Reconciliation note: Both reviewers independently assigned the same score. No disagreement required reconciliation; the agreed score has been recorded.

First scorer rationale: Broad event coverage and a documented retry policy. Two material absences: no HMAC signing/payload verification and no idempotency key or replay endpoint. Mews and Apaleo both document signing; this is a genuine capability gap, not a posture difference. [Rationale correction and anchor disclosure — 2026-08-09] "The score is unchanged at 3. Two of the three conditions stated at anchor 3 are, however, factually contradicted by Cloudbeds primary documentation and are withdrawn as reasons. Withdrawn: that webhooks exist for reservation create and cancel only. Cloudbeds documents events tied to objects and actions spanning reservations, room assignments and guest information. Withdrawn: that no retry exists. Cloudbeds documents a retry policy of one-minute intervals to a limit of five attempts. Self-service registration of multiple endpoints is documented, and delivery is confirmed by 2XX response. Retained: that no payload signing exists. A targeted search additionally established that none of the alternative delivery-authenticity mechanisms admitted at anchor 6 under the v2.4 clarification is documented — no subscription handshake with endpoint verification, no mutual TLS, and no shared secret validated on delivery. The authenticity criterion therefore fails on a full search rather than on a test for cryptographic signing alone. The dimension consequently falls between anchors as drafted. It materially exceeds anchor 3, two of whose three conditions do not hold, while failing a criterion required at anchor 6, and no band exists between them. This is a rubric-drafting matter rather than an evidential gap: no further evidence gathering resolves it. Under the Evidence Reconstruction Principle the published score is not revised mid-cycle. The position is disclosed here and referred to the next scheduled review, where the anchor text falls to be considered for any vendor documenting substantive event coverage and retry without a delivery-authenticity mechanism. This is recorded alongside the equivalent matter logged on Oracle OPERA Cloud's Event-Driven Capability dimension. A comparative point raised in correspondence is addressed for completeness. It was submitted that another vendor holds a higher score on this dimension while issuing a shared secret through a support request. A shared secret validated on delivery is expressly one of the mechanisms admitted at anchor 6 under the v2.4 clarification. That vendor therefore satisfies the authenticity criterion through a permitted mechanism, whereas no such mechanism is documented here. The difference is evidential, not a difference of standard."

Second scorer rationale: Two material webhook gaps (signing, replay) against documented Mews and Apaleo capability. 3 is the correct rubric grade for "limited". [Rationale correction and anchor disclosure — 2026-08-09] "The score is unchanged at 3. Two of the three conditions stated at anchor 3 are, however, factually contradicted by Cloudbeds primary documentation and are withdrawn as reasons. Withdrawn: that webhooks exist for reservation create and cancel only. Cloudbeds documents events tied to objects and actions spanning reservations, room assignments and guest information. Withdrawn: that no retry exists. Cloudbeds documents a retry policy of one-minute intervals to a limit of five attempts. Self-service registration of multiple endpoints is documented, and delivery is confirmed by 2XX response. Retained: that no payload signing exists. A targeted search additionally established that none of the alternative delivery-authenticity mechanisms admitted at anchor 6 under the v2.4 clarification is documented — no subscription handshake with endpoint verification, no mutual TLS, and no shared secret validated on delivery. The authenticity criterion therefore fails on a full search rather than on a test for cryptographic signing alone. The dimension consequently falls between anchors as drafted. It materially exceeds anchor 3, two of whose three conditions do not hold, while failing a criterion required at anchor 6, and no band exists between them. This is a rubric-drafting matter rather than an evidential gap: no further evidence gathering resolves it. Under the Evidence Reconstruction Principle the published score is not revised mid-cycle. The position is disclosed here and referred to the next scheduled review, where the anchor text falls to be considered for any vendor documenting substantive event coverage and retry without a delivery-authenticity mechanism. This is recorded alongside the equivalent matter logged on Oracle OPERA Cloud's Event-Driven Capability dimension. A comparative point raised in correspondence is addressed for completeness. It was submitted that another vendor holds a higher score on this dimension while issuing a shared secret through a support request. A shared secret validated on delivery is expressly one of the mechanisms admitted at anchor 6 under the v2.4 clarification. That vendor therefore satisfies the authenticity criterion through a permitted mechanism, whereas no such mechanism is documented here. The difference is evidential, not a difference of standard."

  • Event coverage is broad across reservations, accommodation, housekeeping, transactions, night audit, door locks, profiles, and events. The surface area of event topics is documented in a per-object table. https://developers.cloudbeds.com/docs/webhooks-1
  • No idempotency key, event ID, or replay/redelivery endpoint is documented. Recovery after consumer downtime requires a full reconciliation pull from the REST API. https://developers.cloudbeds.com/docs/webhooks-1
  • No HMAC signature, signing secret, or payload-signature verification mechanism is documented on the webhooks page. Receivers cannot cryptographically verify Cloudbeds origin. https://developers.cloudbeds.com/docs/webhooks-1
  • Payload includes a version field; whole-number changes denote potentially breaking changes, decimals denote minor changes. Versioning is documented but no schema registry or signed migration path is described. https://developers.cloudbeds.com/docs/webhooks-1
  • Retry policy is documented: on a non-2XX response or server unavailability, the endpoint is retried after a one-minute delay, up to five attempts; after the fifth failure no further calls are made for that event. https://developers.cloudbeds.com/docs/webhooks-1
  • Webhook subscriptions are tied to OAuth permission scopes; for example, reservation/created requires read:reservation. https://developers.cloudbeds.com/docs/webhooks-1
  • Cloudbeds documents webhook events as tied to an object and an action, with worked examples spanning new reservations, room assignment changes and guest contact information changes. Events extend beyond reservation creation and cancellation. https://developers.cloudbeds.com/docs/webhooks-1
  • A targeted search of Cloudbeds webhook documentation located no payload signing mechanism and none of the alternative delivery-authenticity mechanisms admitted at anchor 6: no subscription handshake with endpoint verification, no mutual TLS, and no shared secret validated on delivery. No signing secret is issued on subscription creation. https://developers.cloudbeds.com/docs/webhooks-1
  • Cloudbeds documents a webhook retry policy: on failure, including server unavailability or a non-2XX response, the endpoint is called again after a one-minute delay, repeated until success or a limit of five attempts, after which no further calls are made for that event. https://developers.cloudbeds.com/docs/webhooks-1
  • Cloudbeds documents self-service webhook registration: an integrator registers their own URL endpoint, and may set multiple URLs for a single event or specific endpoints per event. Delivery is confirmed by a 2XX response from the subscriber endpoint. Payload format is versioned, with changes reflected in a version number. https://developers.cloudbeds.com/docs/webhooks-1

Readiness for AI agents

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

Reconciliation note: Primary weights the publicly listed MCP and LLM-native doc surface as best-in-class. Secondary holds that absence of embeddings and an agentic-app showcase prevents a 9. Reconciled at 6: adequate evidence of strong AI-readiness posture without best-in-class proof points across all sub-dimensions. MAD = 3. Stored values refreshed to current live rows; prior primary score row was removed under the anchor-9 corroboration rule. Displayed score unchanged at 6.

First scorer rationale: Real, versioned webhooks confirmed (subscription API, scoped permissions, multiple event types). Official agent-readable llms.txt index confirmed across multiple developers.cloudbeds.com pages — a genuine first-party agent-specific surface, notably absent from every other vendor in the Index. However, Cloudbeds does not publish an official maintained OpenAPI specification (confirmed via independent third party Jentic, who generates and maintains their own spec to fill this gap). Scored 6 to match the standard 'webhooks + spec-equivalent documentation' band; the llms.txt agent-index is flagged separately as a candidate for anchor-9 reconsideration once the anchor reachability rule, which requires anchor 9 to be applied as written, is re-checked against this specific evidence. [Corroboration review — 2026-08-11] "This dimension rests on a single linked evidence row, against the two-row corroboration floor in the published scoring rules, which provides that a dimension documented by a single evidence row caps at 6 until corroborated, regardless of the strength of that single source. The position is disclosed here in accordance with methodology §8b. No corroborating row has been captured, so the dimension is recorded as uncorroborated and is scheduled for a corroboration pass at the next review. The published score is unchanged and is carried under the Evidence Reconstruction Principle."

Second scorer rationale: Strong MCP and LLM-doc posture but no documented embeddings/vector primitives and no agentic-app showcase. Adequate rather than best-in-class.

  • No showcased agentic-apps catalogue is published on the developer surface; agentic-app positioning is weaker than Apaleo Store's Sales Agent, Email Agent, and Migration Agent showcase. https://developers.cloudbeds.com/docs/build-with-llms
  • No native primitives for embeddings, vector retrieval, or semantic search are documented in the developer surface. https://developers.cloudbeds.com/docs/build-with-llms
  • Every developer documentation page carries a banner reading "For AI agents: visit https://developers.cloudbeds.com/llms.txt for an index of all pages formatted in Markdown and endpoints in OpenAPI." Agent-facing wayfinding is rendered in primary doc chrome. https://developers.cloudbeds.com/docs/about-cloudbeds-api
  • Every documentation page is also addressable as raw markdown by appending .md to the URL, explicitly designed for LLM consumption. https://developers.cloudbeds.com/docs/build-with-llms
  • A /llms.txt machine-readable documentation index is published at the documented standard path. https://developers.cloudbeds.com/llms.txt
  • Cloudbeds operates a publicly listed Model Context Protocol (MCP) server at https://developers.cloudbeds.com/mcp, with documented connector instructions for Claude, Cursor, Windsurf, and VS Code. No closed-alpha or limited-release qualifier is attached. https://developers.cloudbeds.com/docs/build-with-llms
  • Cloudbeds publishes real, versioned webhooks (subscription API, scoped permissions, multiple event types) and an official agent-readable llms.txt index across multiple developers.cloudbeds.com pages — a first-party agent-specific surface. No official maintained OpenAPI specification (third-party Jentic generates its own to fill this gap). https://developers.cloudbeds.com/

Data model and multi-property design

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

Reconciliation note: Reconciled to 3. Anchor 6 requires a shared cross-property guest profile and a multi-property hierarchy in the data model. Evidence documents per-property access via the X-Property-Id header and no custom-fields primitive, which matches anchor 3, multi-property as separate instances. Every cohort vendor at 6 evidenced a shared or unified profile or chain-native hierarchy; Cloudbeds evidence does not. Scored on documented capability, not on external knowledge of the platform. [2026-08-09] Corrected from 3 to 9 following the dated score correction recorded in the rationales. The two evidence rows on which the reconciliation rested are superseded: organisation-scoped guest profiles with consolidation primitives, custom fields via postCustomField with applyTo of guest or reservation, and the Insights reporting API are all documented by Cloudbeds. Commercial-access findings are recorded and, under methodology section 11, do not reduce the score. [Reconciliation brought to current position — 2026-08-13] "The current score is 9. Operative reason: organisation-scoped guest profile consolidation, postCustomField with applyTo accepting guest and reservation, and the Insights API reporting surface. Both prior evidence rows are superseded as contradicted by Cloudbeds primary documentation. The text above records the superseded position and is retained unchanged for audit."

First scorer rationale: Single-property feature breadth is strong: canonical PMS resources, a discrete-granularity Accounting API, multi-guest/multi-room reservation structures, and a first-class three-tier Groups and Events model. Multi-property, however, is addressed at the credential and property-ID level via the X-Property-Id header rather than via a unified chain-wide schema. Anchor_6 requires a true multi-property hierarchy in the data model with a shared cross-property guest profile; the evidenced pattern is per-property API access through a header, which describes anchor_3 (multi-property exists as separate instances; reporting requires export), not anchor_6. [Score correction — 2026-08-09] "Data Model Depth moves from 3 to 9. Both evidence rows underlying the previous score are superseded as contradicted by Cloudbeds primary documentation. Anchor 6 criteria, all three evidenced. Shared guest profile across properties: Cloudbeds documents organisation-scoped consolidation of guest records from all properties within an organisation, with merge and unmerge endpoints and system-generated duplicate-candidate suggestions. Multi-property hierarchy in the data model: organisation and property levels are documented, with profile and reservation data attributed within the organisation. Standard reporting API: the Cloudbeds Insights API provides reporting endpoints addressing default and custom reports. Anchor 9 criteria, both evidenced. Unified guest profile with custom attribute support: postCustomField is documented with an applyTo parameter accepting guest and reservation values, operating on organisation-scoped profiles. Real-time reporting API with portfolio-level aggregation: the Insights API provides the reporting surface, and portfolio-level aggregation rests on the documented organisation-scoped consolidation of guest and reservation data across all properties. This second element is recorded as evidenced on that basis rather than on a named per-property parameter, and the basis is stated here for transparency. Two commercial-access findings are recorded and do not affect the score. Organisation-level API access requires a request to Cloudbeds rather than self-serve provisioning, and the Insights API is documented as available to Cloudbeds Insights property users. Section 11 of the published methodology states that v2.0 does not score endpoint gating by commercial tier or partner agreement friction, and the self-serve enablement rule published on 2026-08-09 is non-retrospective and scoped to Operational Programmability and Event-Driven Capability only. Neither finding is a permissible reason to reduce this score, and both are recorded so that they are not reintroduced as such. The score is 9." [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 criteria and clauses relied on are carried forward unchanged into v2.4 and the reasoning holds under it. The score is unchanged."

Second scorer rationale: Strong core model. Header-based multi-property and absent custom-fields cap below best-in-class. [Score correction — 2026-08-09] "Data Model Depth moves from 3 to 9. Both evidence rows underlying the previous score are superseded as contradicted by Cloudbeds primary documentation. Anchor 6 criteria, all three evidenced. Shared guest profile across properties: Cloudbeds documents organisation-scoped consolidation of guest records from all properties within an organisation, with merge and unmerge endpoints and system-generated duplicate-candidate suggestions. Multi-property hierarchy in the data model: organisation and property levels are documented, with profile and reservation data attributed within the organisation. Standard reporting API: the Cloudbeds Insights API provides reporting endpoints addressing default and custom reports. Anchor 9 criteria, both evidenced. Unified guest profile with custom attribute support: postCustomField is documented with an applyTo parameter accepting guest and reservation values, operating on organisation-scoped profiles. Real-time reporting API with portfolio-level aggregation: the Insights API provides the reporting surface, and portfolio-level aggregation rests on the documented organisation-scoped consolidation of guest and reservation data across all properties. This second element is recorded as evidenced on that basis rather than on a named per-property parameter, and the basis is stated here for transparency. Two commercial-access findings are recorded and do not affect the score. Organisation-level API access requires a request to Cloudbeds rather than self-serve provisioning, and the Insights API is documented as available to Cloudbeds Insights property users. Section 11 of the published methodology states that v2.0 does not score endpoint gating by commercial tier or partner agreement friction, and the self-serve enablement rule published on 2026-08-09 is non-retrospective and scoped to Operational Programmability and Event-Driven Capability only. Neither finding is a permissible reason to reduce this score, and both are recorded so that they are not reintroduced as such. The score is 9." [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 criteria and clauses relied on are carried forward unchanged into v2.4 and the reasoning holds under it. The score is unchanged."

  • Multi-guest, multi-room reservation structures are supported with primary/secondary guest distinction and per-room arrays for adults and children. https://developers.cloudbeds.com/docs/reservation-faqs
  • Groups and Events introduces a three-tier Profile, Event, Allotment-Block model for group business, with first-class group and event entities. https://developers.cloudbeds.com/docs/event-management
  • No documented custom-fields or metadata-extension primitive on core entities in the developer surface reviewed. https://developers.cloudbeds.com/docs/about-cloudbeds-api
  • Multi-property is addressed at the credential and property-ID level through the X-Property-Id header rather than via a unified chain-wide schema visible in the developer docs. This is per-property API access, not a chain-native data hierarchy with a shared cross-property guest profile, so anchor_6 of the data model depth rubric (multi-property hierarchy in data model) is not cleared; the evidenced pattern matches anchor_3 (multi-property exists as separate instances). https://developers.cloudbeds.com/docs/void-adjustments
  • Accounting model is exposed via a dedicated Accounting API with transactions filterable by source kind (RESERVATION, HOUSE_ACCOUNT, and others) at discrete double-entry-style transaction granularity. https://developers.cloudbeds.com/docs/accounting
  • Canonical resources exposed include hotel details, reservations, guests, rooms, room types, house accounts, taxes and fees, sources, items, add-ons, payments, and groups. https://developers.cloudbeds.com/docs/about-cloudbeds-api
  • Cloudbeds documents postCustomField as an API operation to create custom fields, with an applyTo parameter whose enumerated values are reservation and guest ("applies the custom field to reservations in myfrontdesk" and "applies the custom field to guest interface in myfrontdesk"), and a paired getCustomFields operation with display targeting to booking engine, reservation folio or registration card. Cloudbeds integration guides document its use to create custom fields on both reservation and guest entities, populated via putReservation and putGuest respectively. https://developers.cloudbeds.com/v1.2/reference/post_postcustomfield-1
  • Cloudbeds documents an Insights API providing endpoints to obtain data available in the Cloudbeds Insights tool, for accounting, reporting and business intelligence use cases, addressing both default Cloudbeds Reports and user-created Custom Reports by name and identifier. The documentation states the Insights API is available to Cloudbeds Insights property users. The reference surface documents dataset endpoints spanning financial, guest, reservations, occupancy, payments, invoices and housekeeping datasets, with a per-dataset last-updated endpoint. https://developers.cloudbeds.com/docs/introduction-to-cloudbeds-insights-api-1
  • Cloudbeds documents guest profiles as organisation-scoped rather than property-scoped. The Guest Profiles API is served at /guest-profiles/v1 and every profile operation takes an organisation identifier parameter, returning profiles across the properties within that organisation, with reservation and stay data attributed to the property within the organisation. The same API documents profile consolidation primitives: merge and unmerge operations, the profiles merged into a given profile, and a suggested-merges endpoint that returns system-generated duplicate candidates for linking. https://developers.cloudbeds.com/reference/get_profiles

Developer tooling and sandbox

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

Reconciliation note: Reconciled to Adequate (6). The secondary reviewer documented the ReadMe interactive reference, public changelog, and structured getting-started flow, all of which satisfy anchor 6 (Self-serve sandbox; at least one official SDK; interactive API reference (Swagger/Postman); changelog published). The primary reviewer's anchor 3 reading treated the partner-gated sandbox as decisive; this audit finds the gating model alone insufficient to drop below anchor 6 when interactive reference, changelog, and onboarding are in place. Cross-vendor consistency with Protel (also partner-gated, scored 6) supports anchor 6 here.

First scorer rationale: Sandbox access is gated behind multi-step partnership review; no self-serve developer account. Combined with email-only support and a multi-week Limited Release certification gate, this is a material DX gap. Interactive try-it-out and a public changelog stop it falling below 3.

Second scorer rationale: Gated sandbox is the decisive constraint, but ReadMe-hosted interactive reference, public changelog, and structured five-step getting-started flow support an adequate rating.

Uptime and operational discipline

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

Reconciliation note: Both reviewers independently assigned the same score. No disagreement required reconciliation; the agreed score has been recorded.

First scorer rationale: Per-component status page, documented rate limits with notification-before-suspension policy, and a demonstrated multi-month deprecation cycle. No published numerical SLA or historical-incident summary keeps this below best-in-class.

Second scorer rationale: Status page and deprecation cycle are adequate. Absence of public SLA is a parity finding with Mews.

  • A public status page exists at status.cloudbeds.com with per-component status: PMS, Booking Engine, Insights and Reporting, Channel Distribution, Guest Experience, Digital Marketing Suite, Payments, Websites, API, and CBU. https://status.cloudbeds.com
  • Recent-notices feed is maintained day-by-day with maintenance windows logged (for example Guest Experience maintenance 2026-05-19). https://status.cloudbeds.com
  • API rate limits are stated: properties 5 req/sec, technology partners 10 req/sec; exceeding limits may suspend credentials with email notification before reactivation. https://developers.cloudbeds.com/docs/faq
  • Deprecation policy is demonstrated via the v1.1 deprecation cycle (Jan 2025 announcement to 31 March 2025 cutoff), advertised on the docs homepage banner. https://developers.cloudbeds.com/changelog
  • No published numerical SLA, uptime percentage, or historical-incident summary is exposed on the status page or developer docs reviewed. https://status.cloudbeds.com

Security, authentication, and compliance

Score: 3 of 9 (Limited). Weight 8%.

Reconciliation note: Reconciled to 3 per the governance_security anchor_6 gate. Evidence row ba367825 confirms neither SOC 2 Type II / ISO 27001 nor a GDPR DPA is located on the developer-trust surface. Consistent with the stayntouch precedent, where comparable or stronger privacy evidence was reconciled to 3 on the same missing-certification basis. Secondary 6 rested on contract security terms, which the anchor_6 gate does not accept as a substitute for certification. [Precedent qualification — 2026-08-13] "These notes rest on the Stayntouch precedent. That precedent has since been qualified by Stayntouch's own clarification of 2026-08-05, so it is not carried here as an unqualified authority. The score is unchanged and no reason stated above is withdrawn; the reliance is recorded as qualified and the point is referred to the next scheduled review."

First scorer rationale: Anchor_6 requires OAuth 2.0 with scoped permissions PLUS SOC 2 Type II or ISO 27001 PLUS a GDPR DPA. OAuth 2.0 with scoped permissions is documented, but no SOC 2, ISO 27001 or GDPR/Privacy certification statement appears on the developer-trust surface reviewed (where Mews and Apaleo declare theirs), and the API-key-first posture remains the default for technology partners. The evidence therefore directly matches anchor_3: OAuth 2.0 supported; no published SOC 2 or ISO 27001; basic privacy policy only.

Second scorer rationale: Scoped OAuth and explicit security standards are adequate; absence of public certifications on the developer-trust surface prevents 9.

Partner programme and references

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

Reconciliation note: Both reviewers independently assigned the same score. No disagreement required reconciliation; the agreed score has been recorded.

First scorer rationale: Structured multi-stage partner programme with explicit marketing and visibility commitments. Absence of a public developer community forum (gap vs Apaleo) and undisclosed partner economics keep this at adequate.

Second scorer rationale: Programme structure is documented; absent public forum is the decisive gap against Apaleo.

Documentation and changelog discipline

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

Reconciliation note: Both reviewers independently assigned the same score. No disagreement required reconciliation; the agreed score has been recorded.

First scorer rationale: OpenAPI-backed ReadMe reference with interactive execution, dated /changelog with named authors and multi-month deprecation lead time, LLM-native surface (/llms.txt plus .md raw access), per-object webhook event table, and a structured five-step getting-started flow. Best-in-class on documentation surface area and machine-readability. [Evidence reconstruction and disclosure — 2026-08-08] Reconstruction was attempted against Cloudbeds primary documentation for the anchor-9 criteria previously unmapped on this dimension. Outcomes: complete endpoint coverage, dated changelog and documentation recency are evidenced. Versioned with a deprecation policy is not met: Cloudbeds' own developer documentation states the API is provided as-is and that changes to structure, calls or methods are not guaranteed, which is inconsistent with a published versioning and deprecation commitment. A complete error reference is not evidenced: an errors page exists but is published under an in-progress path and does not present as complete. Code examples in two or more languages are not evidenced. These three criteria could not be substantiated and are disclosed in accordance with the v2.4 criterion-coverage clarification. The score is unchanged at 9 under the Evidence Reconstruction Principle; the unmet criteria are recorded for assessment at the next scheduled review.

Second scorer rationale: Documentation surface and machine-readability match Mews and Apaleo. Best-in-class is the correct grade. [Evidence reconstruction and disclosure — 2026-08-08] Reconstruction was attempted against Cloudbeds primary documentation for the anchor-9 criteria previously unmapped on this dimension. Outcomes: complete endpoint coverage, dated changelog and documentation recency are evidenced. Versioned with a deprecation policy is not met: Cloudbeds' own developer documentation states the API is provided as-is and that changes to structure, calls or methods are not guaranteed, which is inconsistent with a published versioning and deprecation commitment. A complete error reference is not evidenced: an errors page exists but is published under an in-progress path and does not present as complete. Code examples in two or more languages are not evidenced. These three criteria could not be substantiated and are disclosed in accordance with the v2.4 criterion-coverage clarification. The score is unchanged at 9 under the Evidence Reconstruction Principle; the unmet criteria are recorded for assessment at the next scheduled review.

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 5 of 17 scored vendors on the PMS Power Index ladder.