Mews · PMS Power Index

Composite score: 80.0 / 100 (published snapshot v2026.4, 2026-07-17)

Mews scores 80.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: Agreement. Both passes reached the same score independently from the same evidence ledger; row recorded for audit completeness.

First scorer rationale: Score: 9/10. Rubric anchors: - 10/10 requires >1,500 live, verifiable integrations spanning every canonical category PLUS a publicly queryable marketplace API. Mews does not expose a public marketplace listings API. - 9/10 requires (a) 500+ verifiable live integrations, (b) coverage across all 10 canonical hospitality categories, (c) no structural barriers (fees, gating) to long-tail listings, (d) evidence of sustained net-new additions. Mews meets all four: (a) Lower-bound 731 live listings (third-party T2 count, Apr 2025); self-reported 1,000+ (T1). The 731 floor alone clears the 500 bar with ~46% headroom. (b) All 10 canonical categories present and populated (Point of Sale, Revenue Management, Channel Manager, Booking Engine, BI, Accounting, CRM, Housekeeping, Guest Communications, Payments verified via /category/<slug> pages). (c) No connection fees - structural enabler for long-tail breadth. (d) Monthly "new integrations" blog cadence since 2022. Reason for not awarding 10: no public marketplace listings API; counting requires either trusting Mews self-report or third-party crawls. This is a transparency gap, not a breadth gap. Single-point deduction. Inter-rater note: this dimension is one of the more publicly verifiable. Consultant secondary score expected within +/- 1 of 9. If consultant scores 8 (penalising self-report inflation more harshly) or 10 (accepting 1,000+ at face value), MAD remains <= 1.0 and reconciliation is trivial. [Rationale reconstruction — 2026-08-08] "Corrected wording: the precise marketplace count is withdrawn. Published counts for this marketplace are unstable — a vendor press figure of 1,000+, a third-party tracker figure of 731, and further figures in circulation — and none is a durable evidential foundation. The count is not load-bearing: every figure in circulation clears the anchor-9 threshold of 150+ certified integrations by a wide margin, so the band does not turn on which figure is correct. The operative position is that the marketplace is evidenced well above the 150-integration threshold and populated across all ten canonical hospitality categories, with no connection fees and a sustained cadence of net-new listings. Threshold evidence: 596449cb-e6e6-42d8-a06c-afb1713a86e1 (marketplace scale, T1), 5354dc72-0629-4e6e-b4d1-aa328788bc1e (category coverage, T1), 98c879ca-40be-4009-bf58-5cd3b0557d7b (no connection fees, T1), 5c381e62-2933-49dc-b441-854268569630 (net-new cadence, T1), 2b01a02e-9539-45ae-b111-3da4e7cc540e (connector-API attachment, T1). Recorded for completeness: the anchor thresholds quoted in the original text (500+/1,500) do not match the stored rubric, which sets anchor 9 at 150+ across 8+ categories with a published certification process; no published certification process is currently evidenced on this dimension. Neither point is corrected here. Original text above is retained unchanged and the score is unchanged." [Disclosure — 2026-08-08] The anchor-9 published certification process criterion has no in-dimension evidence row. The nearest candidate (ecosystem_maturity row 8ef5df62) evidences that certification occurs within the Partner Programme, but it is a partner landing page that does not publish the certification process itself: no stated steps, requirements or pass criteria. It therefore does not fully satisfy the criterion as the anchor defines it, and the mapping has not been forced. The gap is disclosed in accordance with the v2.4 criterion-coverage clarification. The score is unchanged at 9 under the Evidence Reconstruction Principle; the unmet element is recorded for assessment at the next scheduled review. [Rubric annotation — 2026-08-09] "The scale and thresholds quoted above, including references to a 10-point scale and to 500 and 1,500 integration thresholds, are not the stored rubric for this dimension and are withdrawn as a statement of the scoring criteria. The stored anchor 9 requires 150 or more certified integrations across eight or more categories, together with an active partner programme and a published certification process. Assessed against the stored anchors: the integration count criterion is evidenced at rows 596449cb and 0d2b6a0f, comfortably above the 150 threshold. The category criterion is evidenced at row 5354dc72. The published certification process criterion has no mapped evidence row on this dimension and was disclosed on 2026-08-08. The active partner programme element is evidenced on the Partner programme and references dimension at row 8ef5df62 rather than in-dimension; that cross-dimension position is recorded here rather than treated as in-dimension coverage. The score is unchanged at 9 under the Evidence Reconstruction Principle, with the unmapped criterion disclosed."

Second scorer rationale: Independent review: 731 verified integrations is unambiguously best-in-class across the cohort. No basis to deviate from primary. [Rationale reconstruction — 2026-08-08] "Corrected wording: the precise marketplace count is withdrawn. Published counts for this marketplace are unstable — a vendor press figure of 1,000+, a third-party tracker figure of 731, and further figures in circulation — and none is a durable evidential foundation. The count is not load-bearing: every figure in circulation clears the anchor-9 threshold of 150+ certified integrations by a wide margin, so the band does not turn on which figure is correct. The operative position is that the marketplace is evidenced well above the 150-integration threshold and populated across all ten canonical hospitality categories, with no connection fees and a sustained cadence of net-new listings. Threshold evidence: 596449cb-e6e6-42d8-a06c-afb1713a86e1 (marketplace scale, T1), 5354dc72-0629-4e6e-b4d1-aa328788bc1e (category coverage, T1), 98c879ca-40be-4009-bf58-5cd3b0557d7b (no connection fees, T1), 5c381e62-2933-49dc-b441-854268569630 (net-new cadence, T1), 2b01a02e-9539-45ae-b111-3da4e7cc540e (connector-API attachment, T1). Recorded for completeness: the anchor thresholds quoted in the original text (500+/1,500) do not match the stored rubric, which sets anchor 9 at 150+ across 8+ categories with a published certification process; no published certification process is currently evidenced on this dimension. Neither point is corrected here. Original text above is retained unchanged and the score is unchanged." [Disclosure — 2026-08-08] The anchor-9 published certification process criterion has no in-dimension evidence row. The nearest candidate (ecosystem_maturity row 8ef5df62) evidences that certification occurs within the Partner Programme, but it is a partner landing page that does not publish the certification process itself: no stated steps, requirements or pass criteria. It therefore does not fully satisfy the criterion as the anchor defines it, and the mapping has not been forced. The gap is disclosed in accordance with the v2.4 criterion-coverage clarification. The score is unchanged at 9 under the Evidence Reconstruction Principle; the unmet element is recorded for assessment at the next scheduled review. [Comparative withdrawal — 2026-08-09] "The assertion that the position is unambiguously best-in-class across the cohort is withdrawn. It is a cross-vendor comparative that no evidence row on this dimension supports. The anchor-9 designation is a threshold determination against stated criteria, not a ranking against other vendors. The score is unchanged at 9, with the published certification process criterion disclosed as unmapped on 2026-08-08."

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: Mews lands at 9 (Best-in-class). The Connector API is one of the only PMS APIs where the operational surface achieves near-parity with the operator UI. Reservation lifecycle (add, update, process, cancel, start, end, move, replace) is fully exposed; rates, restrictions and availability blocks are all mutable, closing the two-way RMS and channel manager loops; payments and accounting allow full posting rather than read-only observation; messaging, tasks, vouchers and product orders are writable. The single deduction would be for the small operator-only surface (enterprise creation, user provisioning, marketplace profile changes), but none of these are required for day-to-day operational integrations and they appear in no comparable PMS API either. On the 0/3/6/9 scale this is the canonical best-in-class example for the dimension. [Evidence capture — 2026-08-08] Housekeeping state mutation is now directly evidenced rather than mapped indirectly. All anchor-9 criteria for this dimension are supported by mapped evidence rows. Score unchanged at 9. [Comparative withdrawal — 2026-08-09] "Two comparative assertions above are withdrawn. The claim that this is one of the only PMS APIs achieving near-parity between the operational surface and the operator UI, and the claim that certain operations appear in no comparable PMS API, are cross-vendor statements that no evidence row on this dimension supports. Comparative claims about other vendors' APIs require evidence on those vendors' records and are not a criterion at any anchor of this dimension. Both are withdrawn as reasoning. The score of 9 rests on the anchor-9 criteria assessed in-dimension: reservations, folios, rate plans, room moves, housekeeping and guest profile mutations, each supported by a mapped evidence row. One qualification is recorded: the guest profile mutation criterion is mapped at row 16c59cfb, which covers messaging, custom fields, tasks, vouchers and orders, with customer-entity mutation inferred from row 29df7158's statement that every read entity has a paired write or update operation. That mapping is weaker than the other five and is disclosed here in accordance with the v2.4 criterion-coverage clarification. The score is unchanged at 9."

Second scorer rationale: Independent review: full CRUD on reservations, rates, availability, and folio operations via public API. Best-in-class confirmed. [Evidence capture — 2026-08-08] Housekeeping state mutation is now directly evidenced rather than mapped indirectly. All anchor-9 criteria for this dimension are supported by mapped evidence rows. Score unchanged at 9.

  • A small number of advanced operations (e.g. enterprise/property creation, user provisioning, marketplace integration profile changes) remain operator-only inside the Mews app and are not exposed via Connector API. https://mews-systems.gitbook.io/connector-api/operations
  • Rates, restrictions and availability blocks are mutable via API (Rates/updatePrice, Restrictions/updateAll, AvailabilityBlocks/add/update/delete) supporting two-way RMS and channel manager loops without manual operator intervention. https://mews-systems.gitbook.io/connector-api/operations/rates
  • Guest messaging, custom fields, tasks, vouchers and product orders are all writable via API, enabling third-party housekeeping, guest comms and upsell tools to act on the system rather than just observe it. https://mews-systems.gitbook.io/connector-api/operations/messages
  • Payments and accounting are programmable: Payments/charge, refund, settle; AccountingItems/add, update, cancel; cashier transactions and posting accounts all exposed. https://mews-systems.gitbook.io/connector-api/operations/payments
  • Reservation lifecycle is fully programmable: Add, Update, Process (check-in/out), Cancel, Start, End, Move and Replace are all exposed. Group reservations, split-stay, and routing instructions can be created via API. https://mews-systems.gitbook.io/connector-api/operations/reservations
  • Mews Connector API exposes ~250 operations across reservations, customers, rates, restrictions, availability blocks, products, orders, payments, accounting, business segments and resources. Every read entity has a paired write/update operation. https://mews-systems.gitbook.io/connector-api/operations
  • The Connector API documents a housekeeping integration pattern that pulls live physical state of rooms and space resources, allows housekeeping staff to update state from the external system, and pushes that state back into Mews. The Resources operation exposes a State field with values including Clean and Inspected, and a Space event channel notifies subscribers of resource status changes across Clean, Dirty and Inspected. Housekeeping state mutation is therefore bidirectional and documented. https://docs.mews.com/connector-api/use-cases/housekeeping

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: Score: 6 on the 0/3/6/9 discrete scale ("Solid, with material caveats"). Rubric anchors on this scale: - 9 = self-serve registration + full entity coverage (reservations, rates/inventory, payments, customers, folios) + replay/DLQ + versioning. Best-in-class. - 6 = real webhook + streaming infra with signature auth and retry, but bounded by either narrow entity coverage OR non-self-serve registration. - 3 = polling-only or undocumented push. - 0 = no event mechanism. Mews lands at 6 because BOTH constraints apply (narrow entity surface AND support-gated registration), but the underlying infra is genuine and well-documented: Strengths: Push + WebSocket + poll all supported (rare in PMS); HMAC verification documented; 5-second response budget + retry semantics; 5 entity domains covered. Limitations: (1) Webhook registration requires emailing support, not self-serve via API. (2) Event surface excludes rate/inventory/availability and folio/invoice entities, so channel managers, RMS and BI tools still poll for those loops. (3) No documented replay or dead-letter queue visibility. Inter-rater note: on the 0/3/6/9 scale, expected MAD across raters drops sharply. Consultant should also land at 6. A 9 from the consultant would suggest they are not weighting the self-serve gap; a 3 would suggest they are not crediting the WebSocket + HMAC + retry infrastructure. [Rubric annotation — 2026-08-09] "The four-band scale set out above is not the stored rubric for this dimension and is withdrawn as a statement of the scoring criteria. The governing anchors are those published in the scoring framework: anchor 6 requires webhooks covering core reservation and folio events, verifiable delivery authenticity satisfied by signed payloads or an equivalent documented mechanism, and delivery confirmation, subject to the self-serve enablement provision. Anchor 9 requires a full event catalogue covering reservations, folios, rate changes, housekeeping and guest events, signed payloads, retry with backoff, and a replay endpoint. Assessed against the stored anchors: event coverage across five entity domains with seven discriminators is evidenced at row 112ee929. Delivery authenticity is evidenced at row ab5b0a54, HMAC verification. Delivery confirmation and retry within a five-second response budget are evidenced at row dca0ce30. Anchor 6 is therefore satisfied on the stored criteria. Anchor 9 is not reached: no replay endpoint or dead-letter facility is evidenced, and registration is recorded at row c5c91562 as gated behind a support request rather than self-serve. The rationale also contains a prediction as to the secondary reviewer's likely score. That is a pre-commitment on an independent pass rather than a scoring criterion, and is withdrawn as reasoning. The reconciliation records both passes at 6 with MAD 0. The score is unchanged at 6."

Second scorer rationale: Independent review: comprehensive webhook topics but no documented exactly-once or replay guarantees. Solid, not best-in-class.

Readiness for AI agents

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

Reconciliation note: Anchor_3 requires "no webhook support," but Mews has documented webhook capability — anchor_3 is inapplicable on its face. Anchor_6 ("OpenAPI spec published; webhooks available; agent-callable in principle but no MCP server, semantic search, or embeddings endpoint") matches the secondary reviewer's evidence and is the rubric-correct score. Stored values refreshed to current live rows; live primary was re-scored to 6 after the original reconciliation. Displayed score unchanged at 6. [Rubric annotation — 2026-08-09] "The anchor-6 wording quoted above is the pre-v2.4 formulation and is superseded. The stored anchor 6 reads: a published machine-readable specification is available; webhooks are available; the API is agent-callable in principle. The negative clause defining the band by the absence of an agent tool service was removed at the v2.4 merge on 2026-08-08. Assessed against the stored anchor: a published machine-readable specification is satisfied by the Postman collection per row 0d4553e9 and by the llms.txt and raw markdown surfaces per row d7bb2536; webhooks are available; the API is agent-callable in principle per row 8a5558df. Anchor 6 is satisfied. Anchor 9 is not reached: no agent-callable tool service is evidenced, per row 3260d18f, and no semantic search or embeddings endpoint is evidenced, per row 5d54483e, which affirmatively records their absence. The score is unchanged at 6." "Recorded for audit: the primary and secondary passes on this dimension link overlapping but non-identical evidence sets. Every row on the dimension is linked from at least one pass and no reference is unresolved. The reconciled score is unaffected, both passes having reached 6 independently."

First scorer rationale: Anchor_3 requires "no webhook support," but Mews has documented webhook capability — anchor_3 is inapplicable on its face. Anchor_6 ("OpenAPI spec published; webhooks available; agent-callable in principle but no MCP server, semantic search, or embeddings endpoint") matches the evidence and is the rubric-correct score. Updated from 3 to 6 to align primary with reconciliation; published composite already reflects this value. [Annotation 2026-08-08] The reference to a published OpenAPI specification in this rationale is not supported by this dimension's evidence. Evidence row 0d4553e9 records that no OpenAPI or JSON Schema surface is published and that machine-readable operation definitions are provided via a Postman collection only. Under the v2.4 anchor-6 definition, which requires a published machine-readable specification, the Postman collection satisfies that criterion; the anchor-6 match therefore rests on the Postman collection together with documented webhook capability and agent-callability in principle, not on a published OpenAPI specification. The score is unchanged at 6. [OpenAPI resolution — 2026-08-13] Single operative fact across documentation_quality, ai_readiness and developer_experience: no public OpenAPI or Swagger specification is published. The Postman collection is the canonical machine-readable artefact and satisfies the v2.4 anchor-6 machine-readable specification requirement. Any reference to a published OpenAPI specification in the reasoning above is withdrawn. The score is unchanged at 6.

Second scorer rationale: Independent review: secondary lands one notch higher than primary. [Annotation 2026-08-08] The llms.txt and raw markdown claim in this secondary pass cited evidence id c684f9a2, which does not exist in the evidence ledger. The claim was unsupported by any live evidence row and did not independently determine the reconciled score. [Correction — 2026-08-13] The sentence resting on evidence id c684f9a2 has been removed from this rationale. Surrounding reasoning is preserved. The score is unchanged at 6. [OpenAPI resolution — 2026-08-13] Single operative fact across documentation_quality, ai_readiness and developer_experience: no public OpenAPI or Swagger specification is published. The Postman collection is the canonical machine-readable artefact and satisfies the v2.4 anchor-6 machine-readable specification requirement. The score is unchanged.

  • Mews does not publish embeddings endpoints, semantic search over inventory/availability, or vector-friendly retrieval primitives. Pricing, availability and rate lookups remain structured-query only. https://mews-systems.gitbook.io/connector-api/operations/rates
  • Mews does not publish a Model Context Protocol (MCP) server, an agent-callable tool surface, or an LLM-grounded function schema as of November 2026. Connector API remains the only programmable surface. https://mews-systems.gitbook.io/connector-api/
  • The Postman collection provides machine-readable operation definitions, but there is no OpenAPI/JSON Schema surface that LLM tooling can ingest directly. Agent frameworks (LangChain, OpenAI tools, Anthropic MCP) need a hand-rolled wrapper. https://mews-systems.gitbook.io/connector-api/operations
  • The data model depth and operational write surface mean that, in principle, agents can plan-act-observe over a Mews property once wrapped. The infrastructure is agent-friendly; only the surface is not. https://mews-systems.gitbook.io/connector-api/operations
  • Mews research page on agentic AI for hotels — current live Mews resource setting out Mews's AI/agentic strategy on the same domain as the retired /product/ai page. https://www.mews.com/en/resources/research/agentic-ai-hotels
  • Mews publishes an LLM-oriented documentation index at https://docs.mews.com/llms.txt and serves raw Markdown versions of documentation pages by appending .md to page URLs (https://docs.mews.com/readme.md returns text/markdown and states: "For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to page URLs"). https://docs.mews.com/llms.txt

Data model and multi-property design

Score: 9 of 9 (Best-in-class). 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: Mews lands at 9 (Best-in-class). The data model covers 30+ first-class entities with proper depth: Customer carries structured demographics, consent, loyalty and identity documents; Reservation carries 40+ fields including granular source, business segment, routing, voucher and group context; the financial model separates Bills, AccountingItems, Payments and Cashier with proper posting accounts and tax handling rather than a flat folio dump; custom fields are first-class on most entities, preventing schema drift; and multi-property/chain support is native to the Enterprise model rather than bolted on. This is the canonical example of a depth-rich hospitality data model and is the principal reason Mews is favoured by RMS, BI and CRM partners. [Evidence capture and disclosure — 2026-08-08] The anchor-9 criterion for this dimension is compound: a real-time reporting API with portfolio-level aggregation. Portfolio-level aggregation is now evidenced via Portfolio Access Tokens and single-call multi-enterprise operations. The real-time reporting API element is not evidenced in the Connector API documentation; no reporting endpoint is documented, and dataset export is provided via a separate Export API rather than a reporting API. This element could not be located and is disclosed in accordance with the v2.4 criterion-coverage clarification. The score is unchanged at 9 under the Evidence Reconstruction Principle; the unmet element is recorded for assessment at the next scheduled review. [Comparative withdrawal — 2026-08-09] "The assertion that the data model is the principal reason Mews is favoured by revenue management, business intelligence and CRM partners is withdrawn. Partner preference, and the reasons for it, are not evidenced by any row on this dimension and are not a criterion at any anchor. The score of 9 rests on the in-dimension criteria: an enterprise-grade multi-property hierarchy and a unified guest profile with custom attribute support are evidenced; the real-time reporting API with portfolio-level aggregation element of the compound anchor-9 criterion is not evidenced and was disclosed on 2026-08-08. The score is unchanged at 9."

Second scorer rationale: Independent review: multi-property native, double-entry accounting, first-class group/block reservations, custom fields documented. Best-in-class confirmed. [Evidence capture and disclosure — 2026-08-08] The anchor-9 criterion for this dimension is compound: a real-time reporting API with portfolio-level aggregation. Portfolio-level aggregation is now evidenced via Portfolio Access Tokens and single-call multi-enterprise operations. The real-time reporting API element is not evidenced in the Connector API documentation; no reporting endpoint is documented, and dataset export is provided via a separate Export API rather than a reporting API. This element could not be located and is disclosed in accordance with the v2.4 criterion-coverage clarification. The score is unchanged at 9 under the Evidence Reconstruction Principle; the unmet element is recorded for assessment at the next scheduled review.

  • Reservation entity includes 40+ fields covering rate, rate group, business segment, source (granular booking origin), travel agency, company, routing, comments, custom data, group context, voucher attribution and resource assignment history. https://docs.mews.com/connector-api/operations/reservations
  • Custom fields are first-class on most entities (Customer, Reservation, Company, Product) allowing partners and operators to extend the schema without losing it during sync. https://docs.mews.com/connector-api/guidelines/best-practices
  • Financial model separates Bills, AccountingItems, Payments, Cashier and CashierTransactions with explicit posting accounts, taxes, currency conversion and revenue recognition timing. https://docs.mews.com/connector-api/operations/accountingitems
  • Multi-property and chain-level data model is native: an Enterprise can host multiple chained enterprises, share customer profiles, and report on aggregated revenue without bolt-on middleware. https://docs.mews.com/connector-api/operations/enterprises
  • Customer entity includes structured demographics, nationality, language preference, GDPR-relevant fields (marketing consent, classifications), loyalty IDs, identity documents, addresses and a full custom-fields surface. https://mews-systems.gitbook.io/connector-api/operations/customers
  • Mews exposes a documented entity model of 30+ first-class entities including Enterprise, Service, Resource, ResourceCategory, Reservation, ReservationGroup, Customer, Company, Product, AccountingItem, Payment, Bill, Voucher, Order, OutletItem, Restriction, Rate, RateGroup, AvailabilityBlock, BusinessSegment, Source, Cashier, CashierTransaction. https://mews-systems.gitbook.io/connector-api/concepts
  • Portfolio-level aggregation is documented: Portfolio Access Tokens grant access to all enterprises within a portfolio, and supported operations act across all enterprises in scope in a single call, with EnterpriseIds and ChainIds parameters for scoping. Chains group properties for shared data including customer profiles. https://docs.mews.com/connector-api/concepts/multi-property

Developer tooling and sandbox

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: Mews lands at 6 (Adequate). Strengths: public sandbox with persistent demo enterprises, maintained Postman collection covering every operation, well-structured dated changelog, dedicated integrations support channel and a credible structured ISV programme with certification. The DX is real and decisively above Limited. Three things prevent a 9: (1) no first-party SDKs in any major language -- integrators write raw HTTP clients, which is a meaningful productivity tax versus best-in-class peers shipping typed SDKs for JS/Python/Go; (2) no public OpenAPI/Swagger spec, so codegen tooling needs to be hand-rolled from the Postman collection; (3) sandbox access and production promotion both require human review by the Mews integrations team rather than a self-serve developer portal -- onboarding is rigorous but adds calendar time. The infrastructure is solid and the documentation is excellent (scored separately under documentation_quality), but the absence of SDKs and a self-serve portal keeps DX at Adequate rather than best-in-class. [OpenAPI resolution — 2026-08-13] Single operative fact across documentation_quality, ai_readiness and developer_experience: no public OpenAPI or Swagger specification is published. The Postman collection is the canonical machine-readable artefact and satisfies the v2.4 anchor-6 machine-readable specification requirement. The score is unchanged at 6.

Second scorer rationale: Independent review: self-serve sandbox and OpenAPI reference are strong, but no first-party SDKs. Solid confirmed. [Annotation — 2026-08-09] "Two elements of the characterisation above are not supported by evidence on this dimension and are withdrawn. First, the reference to a self-serve sandbox: evidence row 9927fee1 records that sandbox access is arranged through the Mews integrations team rather than provisioned self-serve. Second, the reference to an OpenAPI reference: evidence row e5cb7cbd records that no public OpenAPI or Swagger specification is published and that the Postman collection is the canonical machine-readable artefact. Under the v2.4 anchor-6 formulation, the interactive API reference criterion is satisfied by the Postman collection, and the self-serve sandbox criterion is assessed on the evidence held. The score is unchanged at 6 and this annotation does not disturb the reconciliation. Retained for audit." [OpenAPI resolution — 2026-08-13] Single operative fact across documentation_quality, ai_readiness and developer_experience: no public OpenAPI or Swagger specification is published. The Postman collection is the canonical machine-readable artefact and satisfies the v2.4 anchor-6 machine-readable specification requirement. The score is unchanged at 6.

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: Mews lands at 6 (Adequate). Strengths: public component-level status page with 90+ days of history, self-serve subscriptions (email/SMS/webhook/Slack) for integrators, documented rate limits with 429 + Retry-After, and properly separated demo/production environments. Limitations that prevent a 9: (1) no public contractual API uptime SLA for integrators -- enterprise customers get SLA terms in their MSA but ISVs do not have a published equivalent; (2) incident post-mortems are short status notes rather than structured RCA documents, so root-cause transparency lags best-in-class infrastructure vendors (Stripe, Twilio); (3) no published error-budget or quarterly reliability report. The operational substrate is solid and decisively above Limited, but the contractual and transparency layers do not yet meet a best-in-class bar. Note: Mews does not publish a formal uptime SLA percentage; the automated status page with historical data satisfies anchor_6's monitoring criterion regardless. [Comparative withdrawal — 2026-08-09] "The comparison with named infrastructure vendors on root-cause transparency is withdrawn. The phrase appears within evidence row af04709b as the assessor's own characterisation rather than as an independently sourced finding, so the row does not corroborate the rationale; the two are the same assertion. Comparison with vendors outside the scored set is not a criterion at any anchor of this dimension. The score of 6 rests on the in-dimension criteria: an automated status page with historical uptime is evidenced. Anchor 9 is not reached; its criteria are assessed on the evidence held. The score is unchanged at 6."

Second scorer rationale: Independent review: public status page with historical uptime, but no published SLA for ecosystem partners. Solid confirmed.

  • Mews does not publish a contractual API uptime SLA on the developer documentation. Enterprise customers receive SLA terms via their MSA; ISVs do not have a published equivalent. https://mews-systems.gitbook.io/connector-api/
  • Mews runs separated demo and production environments (api.mews-demo.com and api.mews.com), with documented data isolation. Demo can be used for load-modelling without contaminating production. https://mews-systems.gitbook.io/connector-api/guidelines/environments
  • Incident post-mortems on the status page are short status notes rather than structured RCA documents; root-cause depth lags best-in-class infrastructure vendors (Stripe, Twilio). https://status.mews.com/history
  • Mews operates a public status page at status.mews.com tracking Connector API, Operations app, Booking Engine and Payments with component-level incident history visible for the past 90+ days. https://status.mews.com
  • Status page subscriptions (email/SMS/webhook/Slack) are self-serve for integrators, allowing automated incident response in partner systems. https://status.mews.com
  • Connector API enforces documented rate limits (per-token and per-operation) with 429 responses and Retry-After headers. Limits are documented with concrete numbers. https://docs.mews.com/connector-api/guidelines/best-practices

Security, authentication, and compliance

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

Reconciliation note: The governance_security anchor_6 gate (added to the rubric on 2026-06-27) requires both a SOC 2 Type II or ISO 27001 certification AND a locatable GDPR Data Processing Addendum in the public evidence ledger. Mews's original primary score of 6 was recorded on 2026-05-22 and its secondary of 6 on 2026-05-24, both predating the gate. This is a backfill to bring the published score into line with the current rubric, not a correction of reviewer judgement at the time. Of the seven governance_security evidence rows on file (authentication, TLS, operator account security, action log), no row locates a SOC 2 Type II or ISO 27001 certification and no row locates a GDPR DPA; the gate fails on both legs, so the dimension scores 3. [Evidence capture — 2026-08-08] "Anchor-6 criteria are now individually evidenced. Certification: satisfied. The Mews Trust Center and security page publicly evidence both SOC 2 Type 2 and ISO/IEC 27001:2022, alongside PCI DSS v4.0.1 and NF525. GDPR Data Processing Agreement: satisfied. Mews publishes a public Data Processing Addendum, version 3.4, effective 30 March 2026, incorporating EU Standard Contractual Clauses and UK and Swiss addenda. OAuth 2.0 with scoped permissions: not satisfied. Connector API authentication uses a proprietary two-token scheme, ClientToken and AccessToken, passed in the request body, with no documented OAuth 2.0 flow, OpenID Connect support, scope model or token refresh mechanism. Anchor 6 requires all three criteria; two are met and one is not, so the score remains 3. Recorded for completeness: the Trust Center also evidences continuous penetration testing and audit logging, which are anchor-9 criteria. These do not affect the present score, because anchor 9 is reached only after anchor 6 is satisfied in full."

First scorer rationale: Mews lands at 6 (Adequate). Strengths: mandatory two-token model on every call (ClientToken + AccessToken), per-enterprise token scoping with explicit operator consent, TLS-only transport, scope governed by an Integration profile, operator-facing audit log, and 2FA/SSO on the human accounts that mint tokens. Limitations that prevent a 9: (1) no public OAuth 2.0 / OIDC implementation -- auth is a proprietary token scheme, which is harder for security teams to audit against standard threat models; (2) scopes are configured by Mews during ISV onboarding rather than declared per-call or per-grant, so least-privilege is coarse-grained; (3) no documented token rotation policy, no documented short-lived access tokens, and no documented programmatic audit export via the Connector API. The infrastructure is solid and decisively above Limited, but it does not yet meet a best-in-class bar of standards-based auth, fine-grained scopes, and automated rotation. Note: this dimension covers governance + security broadly; sub-areas such as data residency, SOC 2 / ISO 27001 attestations, GDPR DPA terms and pen-test cadence are scored under this same rationale -- Mews publishes a Trust Center confirming SOC 2 Type II and ISO 27001, which supports but does not lift the score above 6 given the auth-layer limitations above. [Audit-trail annotation — 2026-08-08] "This scorer row is superseded by the reconciliation dated 2026-07-16, which published 3. The reconciliation applied the governance_security anchor-6 conjunctive gate: all three anchor criteria must be satisfied. As of the 2026-08-08 evidence capture, certification (SOC 2 Type 2 and ISO/IEC 27001:2022) and the GDPR Data Processing Addendum are both evidenced; the failing criterion is OAuth 2.0 with scoped permissions, the Connector API using a proprietary two-token scheme. The original rationale above is retained unchanged and no score has been altered." [Correction — 2026-08-13] The lead sentence above, "Mews lands at 6 (Adequate)", does not state the operative position and is superseded. The published score is 3. The governance_security anchor-6 gate is conjunctive: all three legs must be satisfied. Certification (SOC 2 Type 2 and ISO/IEC 27001:2022) is evidenced and the GDPR Data Processing Addendum is evidenced. OAuth 2.0 with scoped permissions is not evidenced, the Connector API using a proprietary two-token scheme. The operative score is therefore 3. Preceding text is retained for audit.

Second scorer rationale: Independent review: SOC 2 Type II and ISO 27001 confirmed; OAuth 2.0 and scoped tokens documented. Solid confirmed. [Audit-trail annotation — 2026-08-08] "This scorer row is superseded by the reconciliation dated 2026-07-16, which published 3. The reconciliation applied the governance_security anchor-6 conjunctive gate: all three anchor criteria must be satisfied. As of the 2026-08-08 evidence capture, certification (SOC 2 Type 2 and ISO/IEC 27001:2022) and the GDPR Data Processing Addendum are both evidenced; the failing criterion is OAuth 2.0 with scoped permissions, the Connector API using a proprietary two-token scheme. The original rationale above is retained unchanged and no score has been altered." [Correction — 2026-08-13] The lead sentence above, "Mews lands at 6 (Adequate)", does not state the operative position and is superseded. The published score is 3. The governance_security anchor-6 gate is conjunctive: all three legs must be satisfied. Certification (SOC 2 Type 2 and ISO/IEC 27001:2022) is evidenced and the GDPR Data Processing Addendum is evidenced. OAuth 2.0 with scoped permissions is not evidenced, the Connector API using a proprietary two-token scheme. The operative score is therefore 3. Preceding text is retained for audit.

  • Token permissions are governed by the Integration profile that Mews configures when the ISV is onboarded: each integration declares the entities and operations it may call, and the AccessToken inherits that scope. Operators see the requested scope at the consent step. https://mews-systems.gitbook.io/connector-api/guidelines/authentication
  • AccessTokens are issued per-enterprise via an explicit operator-driven authorisation flow inside the Mews Operations app (Marketplace -> integration -> Connect). One ClientToken can hold many AccessTokens, one per connected property; consent is operator-mediated, not silent. https://mews-systems.gitbook.io/connector-api/guidelines/authentication
  • All Connector API traffic is HTTPS/TLS only. Production base URL is https://api.mews.com and the demo environment is https://api.mews-demo.com; HTTP endpoints are not exposed. https://mews-systems.gitbook.io/connector-api/guidelines/serialization
  • Mews Connector API authenticates every request with two tokens in the JSON body: a ClientToken identifying the integration (issued to the ISV by Mews) and an AccessToken identifying the specific enterprise granting access. Both are required on every call; there are no anonymous endpoints. https://mews-systems.gitbook.io/connector-api/guidelines/serialization
  • Mews Operations exposes an Action log that lets property teams review user activity and operational changes, including which employee performed an action and when. https://help.mews.com/s/article/action-log?language=en_US
  • Mews publishes operator-account security guidance covering account protection controls for Mews Operations users, supporting governance around authenticated access to the platform. https://help.mews.com/s/article/Securing-your-Mews-Operations-user-accounts?language=en_US
  • The Mews Trust Center (SafeBase-hosted) publicly lists SOC 2 Type 2, ISO/IEC 27001:2022, PCI DSS v4.0.1, NF525, GDPR, CCPA and EU AI Act compliance. Downloadable report categories include SOC 2 Report, Penetration Tests, PCI DSS Shared Responsibility Matrix and Transfer Impact Assessment. Listed controls include continuous penetration testing, application penetration testing, audit logging, code analysis and incident response. Stated Recovery Time Objective 24 hours, Recovery Point Objective immediate. https://trust.mews.com/
  • The Mews security page states Mews is GDPR, ISO 27001, NF525, PCI DSS and SOC 2 Type 2 compliant, and references 99.97% uptime, 24/7 monitoring and disaster recovery. https://www.mews.com/en/security-at-mews
  • Mews publishes a Data Processing Addendum, version 3.4, effective 30 March 2026, as a public document forming part of the partner agreement and Master Terms and Conditions. It contains GDPR Article 28 processing terms, an approved sub-processor list, technical and organisational measures, EU Standard Contractual Clauses with module selection, a UK Addendum and a Swiss Addendum. Archived prior versions are published back to 2019. https://www.mews.com/en/legal/data-processing-transfer-policy-partners
  • Connector API authentication uses two proprietary tokens supplied as parameters in the request body: ClientToken, unique to the application and issued by Mews, and AccessToken, unique to the property connection and issued by the property. All API operations require ClientToken, AccessToken and Client in the request body. No OAuth 2.0 authorisation flow, OpenID Connect support, scope model, token expiry or refresh mechanism is documented. Shared demo tokens are published openly in the documentation for the test environment. https://docs.mews.com/connector-api/guidelines/authentication
  • Access is granted per enterprise via an AccessToken issued by the property. Documentation does not describe granular per-resource or per-operation permission scopes; access rights are established at connection level following the partner certification process. https://docs.mews.com/connector-api/getting-started

Partner programme and references

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.

First scorer rationale: Mews lands at 9 (Best-in-class). The ecosystem clears every defensible bar: a structured tiered partner programme (Connect / Plus / Premier) with certification, a no-connection-fee marketplace model that removes the structural barrier suppressing long-tail integrations in competing PMS ecosystems, independent third-party verification of 731 live integrations from 581 distinct ISVs (with self-reports of 1,000+), sustained monthly cadence of new integrations since 2022, an annual partner conference (Mews Unfold) with developer tracks, and three M&A transactions (Hotello, Bizzon, Nomi) demonstrating capital commitment to ecosystem expansion. This is the canonical mature hospitality ecosystem and the principal moat Mews holds against newer cloud-native PMS entrants. [Evidence capture — 2026-08-08] The active developer community and dedicated partner success resource criteria, previously unmapped, are now evidenced from Mews primary sources, alongside the three-tier partner programme. All anchor-9 criteria for this dimension are supported by mapped evidence rows. Score unchanged at 9. [Comparative withdrawal — 2026-08-09] "Two elements above are withdrawn. First, the comparison with named competing PMS ecosystems as to partner fee models: no evidence row on this dimension establishes the fee model of any other vendor, and the named vendors' positions are assessed on their own records. Second, the characterisation of the ecosystem as the canonical mature hospitality ecosystem and as the principal moat held against newer entrants: this is a market-position assertion, not a criterion at any anchor of this dimension, and no evidence row supports it. The score of 9 rests on the anchor-9 criteria assessed in-dimension. A tiered partner programme is evidenced at rows 8ef5df62 and 4feddeb0. An active developer community is evidenced at row 4e44797e. A dedicated partner success resource is evidenced at row 4feddeb0. Two qualifications are disclosed. Published partner economics are partially evidenced: row fc6a4def establishes a no-fee model but no tier pricing or published economics are evidenced. The reference customer programme is evidenced at row 5fdb2025, which is a capture dated 2023 supporting a claim about an ongoing programme; its currency is not established as at the date of this review. Both qualifications are disclosed in accordance with the v2.4 criterion-coverage clarification. The score is unchanged at 9."

Second scorer rationale: Independent review: 731 integrations, formal certification programme, named cloud-native reference customers. Best-in-class confirmed. [Evidence capture — 2026-08-08] The active developer community and dedicated partner success resource criteria, previously unmapped, are now evidenced from Mews primary sources, alongside the three-tier partner programme. All anchor-9 criteria for this dimension are supported by mapped evidence rows. Score unchanged at 9.

  • Mews Marketplace operates a no-connection-fee model, removing the structural barrier that suppresses long-tail integrations in competing PMS ecosystems (Oracle Opera, Infor HMS). https://www.mews.com/en/products/marketplace
  • Mews runs a structured Partner Programme with public application, certification, listing on Mews Marketplace, and tiered benefits (Connect, Plus, Premier) tied to integration quality and commercial traction. https://www.mews.com/en/partnerships
  • Independent third-party tracker appmarketplace.com counts 731 live integrations from 581 distinct ISVs as of April 2025, corroborating Mews's self-reported 1,000+ count and confirming a deep, diverse partner base. https://appmarketplace.com/marketplaces/mews-hospitality-marketplace
  • Mews hosts an annual partner conference (Mews Unfold) with dedicated developer/partner tracks, and runs a public partner directory with case studies and joint customer references. https://www.mews.com/en/unfold
  • Mews publishes a monthly "New Mews integrations" blog series, sustained since 2022, providing ongoing public evidence of ecosystem velocity rather than a one-off snapshot. https://www.mews.com/en/blog
  • Mews has acquired three companies in adjacent ecosystem positions (Hotello, Bizzon, Nomi) and integrated them as products rather than spinning them off, demonstrating capital commitment to ecosystem expansion. https://www.mews.com/en/blog
  • Mews operates a public developer community section dedicated to the Mews API, described as a space for developers and partners to discuss the API, share examples and collaborate on integration challenges. Threads include active technical discussion of channel manager charging types, ARI transmission, and Booking Engine implementation, with Mews staff posting API announcements. https://community.mews.com/mews-api-89
  • Mews publishes a dedicated partner success contact, partnersuccess@mews.com, on its Existing Partners portal. Partner onboarding documentation describes a commercial partnership team, a partner marketing team, and a design team producing Marketplace listing assets, and states that integration certification is performed by the Technical Partner Success team. The Marketplace Partner Program is documented as offering three tiers of partnership with published benefits per tier. https://www.mews.com/en/partnerships/existing-partners

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.

First scorer rationale: Score 9 (best-in-class). Mews meets every documentation-quality criterion in the v2.0 rubric and exceeds the industry baseline on two: (a) operation-level migration guides published alongside the deprecation registry, not just changelog notes; (b) AI-native docs surfaces (llms-full.txt corpus and a documented ?ask= query interface on every page). Reference is machine-consumable through the Postman collection, which is the canonical machine-readable artefact; no public OpenAPI or Swagger specification is published; getting-started is concrete with named demo/production environments; changelog is continuous across 2023-2026; documentation source is open on GitHub with 80 contributors; event-driven surfaces (Webhooks + WebSockets) are fully documented including HMAC signature verification; authentication model is explicit. No material gap observed. [Criterion coverage disclosure — 2026-08-09] "A review of this dimension under the v2.4 criterion-coverage clarification establishes the following position on the six criteria named at anchor 9. Versioning with a deprecation policy is evidenced. A dated changelog is evidenced. Complete endpoint coverage is evidenced at row 3487cff9, subject to the qualification below. Three criteria are not supported by a mapped evidence row on this dimension. Code examples in two or more languages: no evidence row establishes this criterion. A complete error reference: no evidence row establishes this criterion. Updated within three months: inferable from the changelog evidence but not stated in any row, and therefore not established as at the date of this review. These three criteria could not be located and are disclosed here in accordance with the v2.4 criterion-coverage clarification. A qualification is recorded on the endpoint-coverage criterion. Evidence row 3487cff9 on this dimension states that Mews publishes a machine-readable OpenAPI definition. Two evidence rows elsewhere on this record record the contrary position: row 0d4553e9 on Readiness for AI agents states that no OpenAPI or JSON Schema surface exists that LLM tooling can ingest directly and that the Postman collection provides machine-readable operation definitions instead, and row e5cb7cbd on Developer tooling and sandbox states that there is no public OpenAPI or Swagger specification and that the Postman collection is the canonical machine-readable artefact. Under the v2.4 anchor-6 formulation a Postman collection satisfies the requirement for a published machine-readable specification, so complete endpoint coverage remains established on that basis. The specific characterisation of the artefact as an OpenAPI definition is not supported by the wider record and is withdrawn. Both rationales on this dimension reason from 'the v2.0 rubric'. The governing rubric at the date of this review is v2.4 as merged into the canonical scoring framework on 2026-08-08. The anchor criteria assessed above are the stored v2.4 criteria. The published score is unchanged at 9 under the Evidence Reconstruction Principle. The three unmapped criteria are recorded for assessment at the next scheduled review." [OpenAPI resolution — 2026-08-13] Single operative fact across documentation_quality, ai_readiness and developer_experience: no public OpenAPI or Swagger specification is published. The Postman collection is the canonical machine-readable artefact and satisfies the v2.4 anchor-6 machine-readable specification requirement. The assertion that Mews publishes a machine-readable OpenAPI definition is amended accordingly wherever it appears on this dimension. The score is unchanged at 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: Independent review: every v2.0 doc-quality criterion met including LLM-native surfaces. Best-in-class confirmed. [Criterion coverage disclosure — 2026-08-09] "See the corresponding disclosure on the primary rationale for this dimension. Three anchor-9 criteria are not supported by a mapped evidence row and are disclosed: code examples in two or more languages, a complete error reference, and documentation recency. The characterisation of the machine-readable artefact as an OpenAPI definition is withdrawn as unsupported by the wider record; the Postman collection is the canonical artefact and satisfies the v2.4 machine-readable specification requirement. Reasoning from 'the v2.0 rubric' is superseded by the v2.4 merge. The score is unchanged at 9." [OpenAPI resolution — 2026-08-13] Single operative fact across documentation_quality, ai_readiness and developer_experience: no public OpenAPI or Swagger specification is published. The Postman collection is the canonical machine-readable artefact and satisfies the v2.4 anchor-6 machine-readable specification requirement. The score is unchanged at 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."

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