Reference · built on requestConnectorHospitality & property systems

Mews

Reservations, customers, spaces, bills, and tasks from Mews Operations through the Mews Connector API, with webhooks for changes.

About

Mews is a cloud property management system for hotels and hostels. Its Connector API is JSON over HTTPS: every request is a POST under api.mews.com/api/connector/v1 and carries a ClientToken, an AccessToken, and a Client name in the body. Operations cover reservations, customers, services and availability, resources (spaces), bills, payments, products, tasks, and messages. General webhooks deliver events such as ServiceOrderUpdated and ResourceUpdated to one endpoint per integration.

Through Fibric, an operator reads the reservation behind each event and proposes a check-in, a task for a department, or a resource state change for your approval, with a receipt of what changed and how to undo it.

This is a reference listing. It documents what Fibric would read from Mews and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Reservations within the AccessToken's scope through reservations/getAll/2023-06-06, in states Inquired, Confirmed, Started, Processed, Canceled, Optional, or Requested
  • General webhook events: ServiceOrderUpdated, CustomerAdded, CustomerUpdated, ResourceUpdated, ResourceBlockUpdated, MessageAdded, PaymentUpdated, ProductUpdated
  • Customers, their relationships, and open items through customers/getAll, customers/search, and customers/getOpenItems
  • Resources (spaces) in states Dirty, Clean, Inspected, OutOfService, or OutOfOrder through resources/getAll and resources/getOccupancyState
  • Bills and payments through bills/getAll and payments/getAll; products and their pricing
  • Tasks filtered by department, reservation, or deadline through tasks/getAll; message threads and messages through messages/getAll
  • Service availability and availability blocks, plus channel manager details for reservations

Proposed actions

  • Target capability: propose a check-in (Start reservation) or a check-out (Process reservation), or confirm or cancel a reservation
  • Target capability: propose a task with tasks/add: Name, Description, DeadlineUtc, DepartmentId, and the ServiceOrderId it belongs to; close it with tasks/close
  • Target capability: propose a resource state change with resources/update, to any state except OutOfOrder
  • Target capability: propose a message in a thread with messages/add, or a new thread with Add message thread

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Turn a checkout into a cleaning task

    Watch ServiceOrderUpdated for a reservation reaching Processed, then propose a housekeeping task with a deadline before the next arrival on that space.

    With Clean Sequence, Room Ready

  • Mark the space ready once inspected

    When a Dirty space has no in-house guest and the inspection is logged, propose resources/update to Inspected for the supervisor to approve.

    With Room Ready, DND Check

  • Answer a guest message with the reservation in view

    Subscribe to MessageAdded, read the thread and the reservation behind it, and propose a reply or a department task for approval.

    With Guest Requests, First Response

  • Prepare a late checkout

    Read reservations ending today, check the space's next arrival through its occupancy state, and propose a reservation interval change where the space is free.

    With Late Checkout

Requirements

  • A Mews enterprise that creates the integration and shares its AccessToken; demo and production need separate token sets
  • A ClientToken from Mews; production tokens follow the Mews certification form and a review of the operations you use
  • An HTTPS endpoint that answers webhook POSTs within 5 seconds; Mews registers it through its support team
  • The demo environment at api.mews-demo.com for development; production is api.mews.com
Authentication
A ClientToken that Mews issues to your application after its certification process, plus an AccessToken generated for each enterprise (property) that connects, both sent in the JSON body of every request together with a Client name and version.

Limits

  • 200 requests per AccessToken within 30 seconds, measured on a sliding window, in both demo and production; excess returns 429
  • One General Webhooks endpoint and one Integration Webhooks endpoint per integration client
  • Webhook payloads carry entity ids only; you fetch the entity afterwards, and delivery can lag by several minutes
  • A webhook that fails or takes longer than 5 seconds is re-sent after a few minutes and eventually discarded

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Mews ↗

Questions and answers

Does the Mews Connector API use GET requests?
No. Every operation is an HTTP POST with a JSON body, and the body carries the credentials: ClientToken, AccessToken, and Client. The demo platform is api.mews-demo.com and production is api.mews.com; each environment needs its own tokens.
What does a Mews webhook contain?
An EnterpriseId, an IntegrationId, and an Events array. Each event has a Discriminator such as ServiceOrderUpdated or ResourceUpdated and a Value holding the entity Id. You then call the matching getAll operation to read the entity; Mews recommends one call when several events name the same entity.
What is the request limit on the Mews Connector API?
Mews enforces 200 requests per AccessToken within 30 seconds on a sliding window, in both demo and production. When you exceed it the platform returns 429 Too Many Requests, and the client is expected to back off.
Ask about Mews

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.