Connecting hub. for hotels to Mews: what the API actually exchanges
JVJason Vidalenc··9 min read
Your PMS is in place and doing its job. The question is no longer whether to replace it, but what an operations tool can draw from it, what it sends back, and what to prepare before wiring the two. Here are the four flows, the real go-live sequence, and what the connection will not do.
In shortIn short: what does the hub. × Mews connection do?
Four flows travel through the Mews Connector API, one of them in both directions. Mews sends arrivals and departures, room statuses and guest profiles. hub. for hotels sends back room statuses and room blocks for technical incidents. The connection sits on top of the PMS in place, with no migration and no historical data import, and the PMS remains the source of truth for reservations and billing.
What the connection links — and what it does not
hub. for hotels connects to Mews through the Mews Connector API. The two tools do not replace each other: Mews knows what was sold and to whom; hub. knows what was done and by whom.
That double reading is what makes the whole thing useful. A PMS records a reservation, a stay, an invoice. It does not record whether the handover note was read by the night team, or what was attempted during the two previous interventions on room 204's air conditioning. The connection brings PMS data down to the floor, and sends what happens on the floor back up into the PMS.
It touches neither billing, nor pricing, nor the booking engine: those perimeters stay entirely within the PMS. The full split of functions between the two products is covered in a separate article.
The day's movements feed the team planning and the service checklists. No more printed list in the morning, no more outdated version circulating at 3 pm.
Room status
Both ways
A room set to turn-down or check-out in hub. reaches Mews immediately, and vice versa. Front desk and floors work on the same information at the same moment.
Guest profiles and preferences
From Mews to hub.
VIP status, allergies, recurring requests, stay history: what is entered at reservation becomes a note readable by teams on duty, at the right moment.
Incidents and out-of-order rooms
From hub. to Mews
A room blocked for a technical incident in hub. becomes unavailable for sale in Mews, with no double entry. The block is lifted the same way when the incident closes.
The four Connector API flows; each arrow follows the direction of the data.
What the connection changes in a day of operations
The value of an integration is not measured by the number of synchronised fields, but by the number of checks it removes.
The status is updated from the floor; the front desk sees it without making a call.
In the morning, the head housekeeper opens hub. and sees the real departures, not last night's forecast. Turn-down priorities are already ranked.
At 11 am, a leak is spotted in 204. The incident is entered once, with a photo. The room leaves the sellable stock in Mews within the second, maintenance receives the request, and the history of previous interventions comes up.
At the end of the shift, the handover no longer consists of recounting the day but of validating what stays open: two incidents in progress, a late VIP arrival, a quiet-room request already on record.
What to prepare before connecting
The connection itself takes a few minutes. What takes time is the prior agreement on what each status means.
An active Mews environment and an administrator account. Authorisation is granted from your own environment and withdrawn the same way.
An identical room inventory on both sides. Same numbering, same categories. A room that exists on only one side does not synchronise — it silently drops out of the flow.
Agreed status codes. Turn-down, check-out, out of order, commercial block: decide which system is authoritative for each one before go-live, not during.
A written rule for the sales block. Which level of incident takes a room out of stock, and who is allowed to put it back.
A referent on the hotel side. One person who settles status arbitrations. Without them, the double-reading period drags on.
How the go-live unfolds
Allow one week between authorisation and routine use, then two weeks of double reading. The calendar below is that of a single property: for a group, the first site serves as the template and the following ones go twice as fast.
The go-live fits in a few days: a room mapping, not an IT project.
Step
Duration
What happens
1. Authorisation
Day 1
The hotelier grants Connector API access from their Mews environment. Authorisation is granted and withdrawn on the hotel's side.
2. Inventory mapping
Days 1 to 3
Rooms, categories and departments are paired one by one. This is where naming gaps surface — and where they get fixed.
3. Status arbitration
Days 3 to 5
Each status code gets a master system and a blocking rule. It is an operations meeting, not a technical configuration.
4. Double reading
2 weeks
Teams keep checking in the PMS what they see in hub. You stop the day nobody goes to check any more.
What the connection does not do
An integration is judged as much on what it refuses to do as on what it synchronises.
No historical import. The flow starts at the connection date. Earlier stays remain in the PMS and do not feed the per-room incident histories.
No rate or accounting synchronisation. Neither rates, nor invoices, nor payments travel. The PMS remains sole master of those objects.
No moving of the source of truth. The reservation remains Mews'. If an arrival is disputed, the PMS is right.
No replacing the PMS for the front desk. The front desk keeps working in Mews for everything that touches the stay and the invoice.
No automatic block without a rule. A room only leaves stock if the rule written at step 3 says so. Without a rule, the incident is visible but the room stays sellable.
When the two systems stop saying the same thing
A discrepancy is rarely a synchronisation defect. In practice, it comes from three causes.
A room changed on both sides at the same time. The last event wins. The master-status rule agreed at step 3 keeps it from being the wrong one.
A room missing from the inventory mapping. Created in the PMS after the pairing, it has no counterpart. It then shows up without history, or not at all.
A block lifted in only one system. The incident is closed in hub. but the room was put back on sale by hand in Mews, or the reverse. It is the most frequent case, and the only one that deserves a written instruction.
In all three cases, the control runs the same way: compare the list of out-of-order rooms in hub. with the list of blocked rooms in Mews. Two minutes at the end of the shift are enough during the double-reading period.
Do you need to change PMS to deploy hub.?
No. hub. connects to the PMS in place and imposes no migration. The Mews connection is established through the Mews Connector API, on the hotelier's authorisation from their own Mews environment. No historical data import is needed, and the PMS remains the source of truth for reservations and billing.
The inventory mapping and the status arbitration are done with your teams, not in their place: those two steps decide whether the connection still holds in six months. GROW.Hospitality's consultants run them alongside the audit of your existing operations.
A 15-day trial lets you test the platform, connection included, in your real operating context.
Twenty minutes, your Mews environment and your real movements of the day. If your PMS is not Mews, the demo still happens: the connection sits on the PMS in place.
Frequently asked questions about the hub. and Mews integration
Is hub. for hotels compatible with Mews?
Yes. hub. for hotels connects to Mews through the Mews Connector API. Synchronisation covers arrivals and departures, room statuses, guest profiles and room blocks for technical incidents, with no double entry between the two systems.
What data is exchanged between Mews and hub.?
Four flows are active. Reservations, day movements and guest profiles come down from Mews to hub. Incidents and out-of-order rooms go up from hub. to Mews. Room status travels both ways.
Do you need to change PMS to deploy hotel operations software?
No. An operations tool connects to the existing PMS through an API and does not replace it. The PMS remains the source of truth for reservations and billing, while the operations layer drives execution on the floor.
Why connect your PMS to an operations tool rather than use the PMS alone?
A PMS records what was sold; an operations tool records what was done. Connecting the two removes double entry and the gap between the hotel's theoretical state and its real state at any given moment.
How long does the connection take to set up?
Allow one week between authorisation and routine use, then two weeks during which teams still double-check in the PMS. The authorisation itself takes a few minutes: it is the room mapping and the status arbitration that fill the week.
Does the connection import past-stay history?
No. The flow starts at the connection date. Earlier stays remain viewable in the PMS, but they do not feed the per-room incident histories.
What happens if a room is changed in both systems at the same time?
The last event wins. To keep it from being the wrong one, each status code is given a master system at go-live. It is the only decision in the integration that requires a genuine operations arbitration.
Who authorises the connection between hub. and Mews?
The hotelier, from their own Mews environment. Authorisation is granted and withdrawn on the hotel's side, with no third-party access to the data. Connector API access conditions fall under the framework set by Mews.
JV
Jason Vidalenc
Chief Experience & Commercial Officer, hub. for hotels
Spends more time in service corridors than in meeting rooms. Writes here about what circulates — or fails to — between the front desk and the floors.
