Systems
PMS integration: from check-in to room state, in one flow
ZOMYO ships with its own PMS suite and an open API, so room state, occupancy, energy and staff permissions stay in sync with the property management system the front desk already uses.
- Native PMS suite: room status, energy reports, access control and permissions in one platform
- Open API for third-party PMS, BMS and back-office systems
- On-premise deployment — guest-room data stays inside the property
We reply with the data mapping we would use, and what we need from your vendor.
The integration problem
Room control and the front desk usually live in two different worlds
When the PMS and the room automation do not talk, staff bridge the gap by hand — and the gaps show up exactly when the hotel is busiest.
Rooms ready that are not ready
Housekeeping marks a room clean in one system; the room controls are still in departure state when the guest walks in.
DND discovered by knocking
Service and privacy status live on a doorplate and a card, not in the front-desk system, so staff interrupt guests to find out.
Energy data with no owner
Consumption is visible only in a separate analytics login that nobody in operations opens on a Monday morning.
Two permission models
Door access, room permissions and staff roles are managed in different places, with different ideas of who may enter which room.
In sync
What stays synchronised
The platform keeps one operational record of the property and publishes or consumes it through documented interfaces.
Check-in and check-out
The front desk confirms a stay; the room is marked in use and its automation profile moves from vacant to occupied — lighting, HVAC set point, curtains and DND behaviour change together.
Housekeeping room status
Clean, dirty, inspected and out-of-order states are updated from the same platform and shown to housekeeping on the device view they already carry.
DND and make-up room
Doorplate and panel states feed back so the front desk sees privacy and service requests live instead of walking the corridor.
Access and permissions
Room, floor and role permissions are managed centrally; staff access can be time-limited and revoked from one place.
Energy and alerting
Per-room and per-floor consumption, saving reports and equipment alerts are exported to the same system — not to a separate analytics product.
Multiple properties
One deployment can carry several properties with isolated data and per-property permission models.
Interface
What the integration looks like
We integrate through documented interfaces rather than a closed list of certified vendors — the deciding factor is whether your PMS exposes data you own.
Bi-directional: ZOMYO consumes stay and status records, and publishes room, energy and alert data
Open REST API with a documented data model; RS485 / Modbus / KNX bridges for BMS-side systems
Room status, stay (check-in / check-out), DND and make-up room, occupancy state, energy, alerts
Local server inside the property; integration survives an internet outage
Staff roles and room-level permissions; no guest personal data required for automation
PMS vendor documentation, a test tenant, and your operational room / floor naming
No per-room cloud subscription, no mandatory third-party middleware
Onboarding
How integration runs
Four steps from documentation to a live pilot floor.
- 01
Discovery
Agree which system owns which record — stay, room status, energy — and map your room and floor naming onto the platform.
- 02
Sandbox
We work against a test tenant with sample rooms; every API call and state change is validated end to end before any guest is involved.
- 03
Pilot floor
One floor runs live with both systems in parallel, so front-desk and housekeeping workflows are proven rather than assumed.
- 04
Go live, then scale
Rollout proceeds floor by floor, with pre-sales engineering support and documentation handed to your IT team.
Before you ask your vendor
Integration questions
Do you support our PMS?
We integrate through an open REST API and documented interfaces rather than maintaining a closed vendor list. If your PMS exposes an API, a database view or a documented interface, the work is a mapping and configuration exercise. We start from your vendor documentation and a test tenant, and we tell you early if an interface is genuinely not workable.
Where does the data live?
On a local server inside the property. Guest identity data is not required for automation: the platform works with room, stay and permission records, which keeps the deployment inside your own data-protection scope.
What happens when the PMS or the network goes down?
Room automation is local, so lights, HVAC, curtains and scenes keep working. The platform queues state changes and reconciles with the PMS when the link returns; the front desk keeps operating on the room states it last received.
Can we keep our existing BMS?
Yes. KNX and Modbus bridging keeps the building systems on the same host, so the BMS keeps its own view of HVAC and lighting while ZOMYO handles room-level behaviour.
How long does an integration take?
The API mapping is usually validated in a sandbox within days, and a pilot floor is proven before wider rollout. The schedule depends mainly on how quickly your PMS vendor documentation and test tenant become available.
Can we use our own front-end for staff?
Yes — the API is the interface. Properties that already have a staff app or a corporate dashboard can consume ZOMYO room and energy records directly instead of using the built-in views.
Let us map the interface before the site visit
Send the PMS name, the interface documentation you have, and one test tenant. We reply with the records we would exchange and the questions for your vendor.
Talk to us directly
We normally reply within one business day with a configuration list and a schedule.