RMS Cloud · PMS Power Index

Composite score: 52.3 / 100 (published snapshot v2026.4, 2026-08-08)

RMS Cloud scores 52.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%.

First scorer rationale: 550+ verified integration partners spanning all major hotel tech categories. Native channel manager, POS, payment (RMS Pay), and booking engine all built in. Industry-leading breadth confirmed by partner directory and third-party marketplace listings. [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."

What you can control via the API

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

First scorer rationale: Public REST API documentation at restapidocs.rmscloud.com, a public Postman workspace, and a self-serve developer sandbox are confirmed — together evidencing self-serve access to a documented REST surface. However, no specific write endpoints for reservation lifecycle, folio posting, rate plan mutation, room moves, or housekeeping are individually named in the evidence reviewed. Anchor_9 requires the full operational surface to be confirmed writable; that compound bar is not cleared. Public REST documentation with self-serve developer access is consistent with anchor_6 (core reservation and folio writability) as the defensible middle position pending endpoint-level verification. Score corrected to Adequate (6). Note: a targeted search for anchor_9 evidence found only POST /transactions/void, PUT /sundries/:id, and POST /webhooks publicly enumerable — no reservation-lifecycle, folio-posting, rate-plan, room-move, or housekeeping write endpoints are evidenced, confirming anchor_9 is not supported and the score remains at anchor_6.

Real-time updates and webhooks

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

First scorer rationale: A self-service webhook subscription mechanism is confirmed to exist on the vendor API page. However, no event catalogue, payload schemas, payload signing, retry behaviour, or delivery-confirmation mechanism is publicly evidenced. Anchor_6 requires signed payloads and delivery confirmation; neither is evidenced. The evidence matches anchor_3 (webhooks exist; no payload signing; no retry or replay). Score corrected to Limited (3). [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."

  • Self-service webhook subscription mechanism confirmed on vendor API page (Enable webhook integration with a self-service subscription option to start creating triggers). No event catalogue, payload signing, retry behaviour, or delivery confirmation evidenced. https://www.rmscloud.com/platform/api

Readiness for AI agents

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

First scorer rationale: A REST API exists and is publicly described, clearing anchor 3. No anchor 6 technical artefacts (published OpenAPI specification, agent-callable tool surface, structured webhook payloads suitable for agent consumption) are publicly confirmed. The vendor's "designed to support AI agents" positioning is a marketing claim, not a documented technical capability; treating it as anchor 9 evidence would substitute vendor framing for rubric criteria. Score corrected to Limited (3).

  • Vendor explicitly states API is Designed to support AI agents and agentic workflows and positions open portable APIs for AI capabilities — direct product architecture claim https://www.rmscloud.com/platform/api
  • Vendor promotes industry largest endpoint library and No limits no lock-in positioning — signals AI-era data portability as a core design principle https://www.rmscloud.com/platform/api
  • RMS Cloud positions API as having industry largest endpoint library with no limits and no lock-in — language consistent with a data portability architecture required for AI agent consumption of PMS data at scale. https://www.rmscloud.com/platform/api
  • RMS Cloud API page states Leverage AI capabilities through open portable APIs and Designed to support AI agents and agentic workflows — explicit vendor product architecture claim for AI agent compatibility, not marketing language. https://www.rmscloud.com/platform/api
  • RMS Cloud API page states Leverage AI capabilities through open portable APIs and Designed to support AI agents and agentic workflows — explicit vendor product architecture claim for AI agent compatibility, not marketing language. https://www.rmscloud.com/platform/api
  • RMS Cloud positions API as having industry largest endpoint library with no limits and no lock-in — language consistent with a data portability architecture required for AI agent consumption of PMS data at scale. https://www.rmscloud.com/platform/api
  • Public review of the RMS Cloud developer surface returns no documented OpenAPI specification, no MCP server, no semantic-search or embeddings endpoint, and no structured webhook payloads designed for agent consumption. The vendor's "designed to support AI agents" positioning is a marketing claim; no technical artefacts confirming agent-readiness are publicly evidenced. https://www.rmscloud.com/platform/api

Data model and multi-property design

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

First scorer rationale: Evidence describes real-time two-way data exchange across inventory, rates, booking engines, POS, and CRM. This is integration breadth at the single-property layer, not multi-property data architecture. Anchor_6 requires a shared guest profile across properties and a multi-property hierarchy in the data model; neither is evidenced. The evidence matches anchor_3 (multi-property exists as separate instances; no shared guest profile). Score corrected to Limited (3). [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."

  • Vendor describes real-time two-way data exchange across inventory, rates, booking engines, POS, and CRM. This evidences integration breadth at the property layer, not multi-property data architecture or a shared cross-property guest profile. https://www.rmscloud.com/platform/api

Developer tooling and sandbox

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

First scorer rationale: Sandbox existence is confirmed on the vendor API page. However, no official SDK is named, no interactive API reference (Swagger/Postman try-it) is individually evidenced for this dimension, and no public changelog is cited. Anchor_6 requires sandbox AND SDK AND interactive reference AND changelog; only the sandbox claim is evidenced here. The evidence matches anchor_3 (sandbox available; no SDK; static documentation only). Score corrected to Limited (3). [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."

  • Developer sandbox confirmed on vendor API page alongside vendor statement about clear well-structured docs. No official SDK, interactive try-it reference, or changelog individually evidenced for this dimension. https://www.rmscloud.com/platform/api

Uptime and operational discipline

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

First scorer rationale: Adjusted to 3 on cross-vendor review. Anchor_6 requires an automated public status page; none found. Enterprise deployment via Ariane Systems and 6,500+ properties across 70 countries imply proven uptime at scale, but inferred reliability from scale and partnerships does not substitute for the public reliability artifacts (SLA, status page) the rubric requires at 6. [2026-08-08] Anchor-6 monitoring criterion is met: an automated public status page publishing 90-day historical uptime, with per-API-surface component tracking across four regions, advance maintenance notification and incident records including cause and remediation. No published uptime SLA percentage exists; under the rubric's carve-out, the absence of a published SLA percentage where an automated historically-tracked status page is operated does not by itself reduce the score below anchor 6. Score does not reach 9: anchor 9 requires a published uptime SLA of 99.9% or higher, and no contractual service-level commitment is published.

  • [SUPERSEDED 2026-08-08] Ariane Systems world leader in self-check-in certified RMS Cloud as integration partner confirming production-grade REST API in live enterprise deployment across 3000+ installations https://www.ariane.com/pms-integrations/rms-cloud
  • RMS Cloud operates an automated public status page (Atlassian Statuspage) publishing 90-day historical uptime, with a dedicated historical uptime view and an incident history archive. Components are tracked individually per API surface (RMS REST API, RMS Online API, RMS Public API) across four regions (Australia, North America, China, Europe), each with published uptime figures. Incident records include cause, remediation and resolution updates. Scheduled maintenance is announced in advance with stated purpose and expected impact. Notification subscription is available by email, SMS, Microsoft Teams and webhook. https://status.rmscloud.com
  • The RMS SaaS Terms & Conditions (clause 5.2, Downtime) commit to reasonable efforts to maintain availability and direct customers to the status page for unscheduled downtime, and state that RMS is not liable for interruptions or unavailability. Clause 3.2 provides the Services 'as is' with no warranties. No uptime percentage or contractual service-level commitment is published. https://www.rmscloud.com/terms-and-conditions

Security, authentication, and compliance

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

First scorer rationale: PCI compliance and US Department of Defence IL4 compliance are noted on a LinkedIn company page. These are real certifications but are not the certifications anchor_6 names; anchor_6 requires (SOC 2 Type II or ISO 27001) AND a GDPR DPA AND OAuth 2.0 with scoped permissions. Neither SOC 2/ISO 27001 nor a published DPA is evidenced, and OAuth 2.0 support is not evidenced at all. LinkedIn is also not treated as an authoritative source elsewhere in this index. The evidence matches anchor_3 (OAuth 2.0 not confirmed; no published SOC 2 or ISO 27001; basic privacy posture only). Score corrected to Limited (3). [Evidence update — 2026-08-08] Two of the three anchor-6 criteria are now evidenced from vendor primary documentation: SOC 2 Type II certification (Sensiba LLP, 1 December 2024 to 30 November 2025, all five Trust Services Criteria) and a publicly available GDPR Data Processing Addendum incorporated into the SaaS Terms & Conditions. The third criterion, OAuth 2.0 with scoped permissions, is not evidenced in any located public source. Anchor 6 requires all three criteria, so the score remains 3. The prior evidence row, sourced to a LinkedIn company page, is superseded by the vendor's own security and legal documentation. [Evidence search outcome — 2026-08-09] The anchor-6 gate for this dimension requires three criteria: OAuth 2.0 with scoped permissions, SOC 2 Type II or ISO 27001 certification, and a locatable GDPR Data Processing Agreement. All three are required and, where any is not located in public evidence, the dimension scores 3. Certification and Data Processing Agreement are both evidenced from RMS primary documentation, recorded on 2026-08-08: SOC 2 Type II across all five Trust Services Criteria, audited by Sensiba LLP, covering 1 December 2024 to 30 November 2025 and issued 11 December 2025; and the RMS Data Processing Addendum, a named contractual document incorporated into the RMS SaaS Terms and Conditions and publicly available at the terms page. The OAuth 2.0 with scoped permissions criterion is not evidenced. A targeted search was conducted across the RMS REST API specification surface at restapidocs.rmscloud.com, the RMS public Postman workspace, the SwaggerHub-hosted OpenAPI specification, the RMS support knowledge base, and the RMS SaaS Terms and Conditions. No description of an OAuth 2.0 authorisation flow, authorisation or token endpoint, consent flow, or permission scope model was located. The specification surfaces render client-side or require authentication and did not yield readable authentication documentation to this search. Two independent integration platforms publishing setup documentation for RMS Cloud describe a different mechanism: an agent identifier and agent password, obtained by contacting RMS API support, exchanged for a short-lived access token, alongside a long-lived API key option. Those sources are recorded at tier T3 and are not capable of determining the criterion under the four-tier evidence hierarchy. They are recorded as corroborating the search outcome, not as establishing RMS Cloud's authentication architecture. In accordance with methodology §8b, this records that the search was performed and the criterion was not located on a public surface. It does not assert that OAuth 2.0 with scoped permissions is absent from the RMS API. RMS may submit primary documentation evidencing the criterion at any time through the always-open dispute channel, and the dimension would be reassessed on that evidence. The score is unchanged at 3. Two of three anchor-6 criteria are evidenced and credited; the third is not located. Anchor 6 requires all three. Recorded for the next scheduled methodology review: whether a conjunctive anchor-6 gate, under which a vendor holding an audited SOC 2 Type II attestation across all five Trust Services Criteria, a PCI DSS v4.0.1 Report on Compliance at Service Provider level, and a publicly available Data Processing Addendum scores identically to a vendor with no evidenced security posture, is calibrated appropriately. This affects more than one vendor in the current set and is a rubric-calibration question rather than a scoring question on this record.

  • [SUPERSEDED 2026-08-08] PCI compliance and US Department of Defence IL4 compliance noted on LinkedIn company page. These are not the certifications named in anchor_6 (SOC 2 Type II or ISO 27001 + GDPR DPA), and OAuth 2.0 support is not evidenced. LinkedIn is not treated as authoritative elsewhere in this index. https://www.linkedin.com/company/rms-aust-pty-ltd
  • The RMS Data Processing Addendum is a named contractual document incorporated by reference into the RMS SaaS Terms & Conditions and publicly available at the terms page. https://www.rmscloud.com/terms-and-conditions
  • RMS holds a current SOC 2 Type II attestation across all five Trust Services Criteria, audited by Sensiba LLP, covering 1 December 2024 to 30 November 2025, report issued 11 December 2025. The same page documents a PCI DSS v4.0.1 Report on Compliance at Service Provider level, assessed by PCI Consulting Australia, November 2025. https://www.rmscloud.com/support/security-at-rms
  • Supergood, an integration platform wrapping the RMS Cloud REST surface, describes authentication as an RMS API key or agent credentials exchanged for a short-lived access token, with automated refresh and rotation, and refers to RMS exposing both long-lived keys and short-lived tokens. No authorisation endpoint, consent flow or permission scopes are described. https://supergood.ai/docs/rms-cloud-api
  • Calry, an integration platform publishing setup documentation for RMS Cloud, instructs integrators to obtain an agent_id and agent_password by contacting apisupport@rmscloud.com, and to enter those credentials to authenticate the integration. No authorisation endpoint, consent flow or permission scopes are described. https://docs.calry.app/docs/PMS%20Specific%20Guides/rms-cloud

Partner programme and references

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

First scorer rationale: One verified partner integration (HyperGuest, two-way REST in production) is evidenced. A single named partner is a partner relationship, not programme infrastructure. Anchor_6 requires a self-serve partner programme with published tiers, an active developer forum or community, and a publicly searchable partner directory; none of these are evidenced in the current ledger. The evidence matches anchor_3 (partner relationships exist but programme is undocumented; no developer forum or community). Score corrected to Limited (3). Note: rmscloud.com/partners-integrations is a public partner directory spanning 14 categories with "hundreds of partners," which is genuine evidence toward anchor_6's directory criterion — but published partner tiers and a developer forum/community are not evidenced, so the compound anchor_6 requirement remains unmet. [2026-08-08] Anchor-6 criteria met: self-serve partner programme with published tiers, active public community, and publicly searchable partner directory. Score does not reach 9: anchor 9 requires published partner economics, and the commercial API licence terms are not publicly disclosed.

Documentation and changelog discipline

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

First scorer rationale: A public Postman workspace is confirmed. However, evidence explicitly states no published changelog, no OpenAPI spec download, and no versioning notes were found externally. Anchor_6 requires versioning, recent updates, and a changelog; both versioning and changelog are stated absent. The evidence matches anchor_3 (documentation exists but is unversioned and lacks a changelog). Score corrected to Limited (3). Note: restapidocs.rmscloud.com/changelog returns 404, the Postman workspace contains no changelog, and no versioning policy is evidenced. [2026-08-08] Anchor-6 criteria met: complete endpoint coverage via a public versioned OpenAPI specification, versioning maintained on SwaggerHub, and a published changelog updated within six months. Score does not reach 9: code examples in two or more languages are not evidenced in first-party documentation. SwaggerHub client generation is a platform capability rather than vendor-published multi-language examples.

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