Skip to content

Integrations

Built to be integrated with

A building control system that cannot hear from your property management system is a building control system somebody has to operate by hand. Ours takes reservation and stay events from your PMS, and hands room and plant state to your BMS — over documented interfaces, with the integration running inside the building.

50+
HMS / PMS vendors
9
Event kinds
2
Auth methods
3
BMS routes

Property management systems

Your PMS drives the building

50+ hotel and property management systems already talk to us. Check-in, check-out, room moves and reservations arrive from the system that already owns them, and the PMS stays the authority on occupancy — we do not ask you to maintain the same truth twice.

The integration runs in the building

Your property management system talks to a service on the same local network, not to a cloud endpoint on the other side of the hotel’s internet connection. Events apply in milliseconds, and a bad night on the WAN does not stop a check-in from reaching the room.

You are not gated on our release cycle

Adding a field to your payload used to mean waiting for us to ship. It does not any more. Within the compatibility rules, your side can evolve independently — no coordinated release, no change window shared between two companies.

Your existing integration still works

If you already send us events against the older cloud endpoint, the same payloads are accepted unchanged. A base URL swap is the whole migration. Nothing to rewrite unless you want to.

Nothing is silently dropped

Every event is written down before the response returns, deduplicated against what we have already seen, and acknowledged back to you with what actually happened to it. Retries are safe by design.

Event catalogue

Seven inbound event kinds cover the guest lifecycle, and two outbound kinds report back. Further kinds — service requests, maintenance blocks, folio events, energy and access signals — are already accommodated by the envelope and are implemented when a partner has a concrete need for them.

Check-in

Direction
Inbound
What it does
Guest has checked into a room. Powers the room, opens access, releases setback.

Check-out

Direction
Inbound
What it does
Guest has departed. Starts the housekeeping cycle and applies the vacant-room policy.

Room move

Direction
Inbound
What it does
Guest relocated between rooms. State follows the guest, not the key.

Check-out reversed

Direction
Inbound
What it does
A checkout undone at the desk is undone in the building too.

Reservation opened

Direction
Inbound
What it does
A future booking, used for pre-arrival preparation.

Reservation amended

Direction
Inbound
What it does
Pre-arrival changes — dates, occupancy, room type.

Reservation cancelled

Direction
Inbound
What it does
Booking voided; any prepared state is released.

Room status changed

Direction
Outbound
What it does
The building tells your system when a room’s state changes.

Event acknowledged

Direction
Outbound
What it does
Confirmation of what happened to each event you sent us.

Two ways to authenticate

Pick whichever suits your infrastructure. Both fully authenticate the request; there is no second-class option.

IP allow-list

Fixed IPs

Give us the addresses your system sends from and requests arrive authenticated with no header at all. The simplest option if your infrastructure has stable egress.

Bearer token

Dynamic IPs

Exchange a credential for a short-lived token scoped to your system and one property. Multiple tokens can be live at once, so a primary and a standby server can each hold their own.

Two ways to send

Choose whichever is closer to how your system is already built. You do not need to use both, and neither is the preferred one.

One endpoint

Send every event to a single URL and tell us in the body which kind it is. The fit if your system already has one outbound webhook pipeline it puts everything through.

Discrete endpoints

A separate URL per event kind — check-in, check-out, room move, booking. The fit if your system emits events from separate code paths and you would rather not carry a discriminator.

Opera / Fidelio and Protel are supported alongside the systems listed below, as is anything that can deliver a webhook.

Integrated systems

Systems we already work with

A selection of the property management systems running against PACsys today. It is not the full list — if you do not see the one your properties use, ask, because the integration very often already exists.

  • Aiosell
  • Cheerze Connect
  • eZee
  • Hotelogix
  • IDS
  • InnKey
  • Stayflexi
  • WinHMS
  • and 50+ more

Running something else?

Tell us which system your properties use and we will confirm whether the integration already exists — it usually does. Where it does not, any system that can send a webhook or post to a REST endpoint is a configuration exercise rather than a development project.

Ask about your system sales@tes.ind.in

Are you a PMS or HMS vendor?

Leave your details and we will email you an invitation link to complete the integration registration yourself — no call required to get started.

Building management

Three ways out to your head-end

If you already run a BMS or SCADA system, TCMsys is not asking to replace it. It is asking to be a well-behaved source of room and plant data inside it.

REST

Versioned, with generated OpenAPI documentation. Every room state, event, alarm and configuration object is reachable. The previous major version stays available so your adapter migrates on your schedule, not ours.

WebSocket

Subscribe once and receive state changes as they happen, within a second of the physical event. Built for head-ends that have their own latency commitments to meet.

Modbus server endpoints

For estates standardised on Modbus, the site coordinator exposes server-side endpoints so an existing BMS or SCADA head-end polls room and plant state from its native register map. No bespoke adapter, no middleware box in the riser, no second system for your operators to learn.

A note on fallback. Integration is an enhancement, never a dependency. If the PMS link fails, the system falls back to keycard occupancy and carries on. If the BMS goes away, room control is unaffected. Nothing about the building stops working because another vendor’s system did.

Summary

Every route in and out

REST API

Primary

Every room state, event, alarm and configuration object is reachable over a versioned REST API with generated OpenAPI documentation. Breaking changes bump the major version and the previous major stays available, so a third-party adapter is never forced to migrate on our schedule.

WebSocket push

Realtime

State changes are pushed, not polled. A subscribed BMS or dashboard sees a change within a second of the physical event, and dashboard clients never poll the server.

Modbus server endpoints

BMS / SCADA

For estates standardised on Modbus, the coordinator exposes server-side endpoints so an existing BMS or SCADA head-end can poll room and plant state directly from its native register map — no bespoke adapter, no middleware box in the riser.

PMS events

Hospitality

Check-in, check-out and reservation events arrive by REST or webhook, and the PMS stays the authority on occupancy. Opera / Fidelio, Protel and any system that can deliver a webhook are supported. If the PMS link drops, the system falls back to keycard occupancy — AC control never depends on it.

Integrating with us?

If you are a PMS or BMS vendor, we will send you the full interface guide — payload shapes, authentication, idempotency rules and compatibility guarantees — and put you in touch with the engineer who maintains it. Write to sales@tes.ind.in.

Request a demo sales@tes.ind.in