PMS Connector

The PMS (Property Management System) connector links Kiwire to a hotel's PMS so that a guest check-in, check-out, or room change is reflected on the WiFi network automatically — no front-desk WiFi setup, and no stale access after checkout.

'alt' => 'Dashboard overview', 'caption' => 'The default Kiwire dashboard layout', 'screenshot' => true, 'class' => '', ]) Drop images into: public/assets/img/docs/{page}/{filename} --}}

Image not uploaded yet public/assets/img/docs/connector-pms/overview.png

How It Works

A PMS connector doesn't create WiFi accounts on its own — it activates and suspends accounts that already exist. Before enabling the connector, make sure a WiFi user account exists for every room, with the username set to the room number (create manually or via bulk import under Account → Users).

1. Guest checks in at the front desk (or self-checks-in). The PMS records the reservation against a room.
2. The PMS sends Kiwire a check-in event for that room, using one of the mechanisms below.
3. Kiwire finds the WiFi account whose username matches the room number, sets it to active, and assigns a password based on the connector's Guest Password Setting (room number, first name, last name, full name, or a predefined password).
4. The guest connects to the WiFi SSID and signs in using their room number (or the PMS login method, if configured on the captive portal journey).
5. On check-out, the PMS sends a check-out event and Kiwire suspends the account — active RADIUS sessions are disconnected immediately.

Delivery Mechanisms

The PMS Type you pick decides which of three mechanisms Kiwire uses to receive events. Most cloud/API-based PMS platforms use the Inbound Webhook mechanism — that's what the JSON and GET types are for, and the right choice if your PMS (or a middleware script in front of it) can send an HTTP request whenever a guest checks in or out.

Mechanism	PMS Type	Direction	Setup
Inbound Webhook PMS pushes HTTP to Kiwire	json	PMS → Kiwire	No connection details needed on the Kiwire side — copy the generated URL + token into the PMS/middleware.
	get
	idb (IDB)
	pro (PRO)
	ezee (eZee)
	rhealta (Rhealta)
	comanche (Comanche)
Socket Daemon (FIAS) Kiwire opens a TCP connection to the PMS	opera (Oracle Opera)	Kiwire → PMS	Enter the PMS Host and Port (default 5010). Kiwire runs a background daemon that stays connected.
	infor (Infor HMS)
	oasis (Oasis)
Kiwire Agent A local agent speaks FIAS to the PMS and relays to Kiwire	opera-agent	PMS → Agent → Kiwire	Use when Kiwire can't reach the PMS directly (isolated hotel LAN). Install the downloadable agent on a machine with network access to the PMS.
	infor-agent
	oasis-agent

Core Fields

Field	Description
Active	Enable or disable this connector instance without deleting it.
Name	A label to tell instances apart (e.g. "Hotel A", "PMS Primary", "Backup") — you can run multiple PMS connectors per tenant.
PMS Type	Which mechanism and payload format to use — see the table above.

Inbound Webhook Setup (JSON, GET, IDB, PRO, eZee, Rhealta, Comanche)

After saving the connector with one of these types, Kiwire generates a unique webhook URL and token for it, shown on the connector form:

https://your-kiwire-domain.com/pms/inbound/{tenant_id}
Token: <40-character random string>

Give this URL and token to your PMS vendor (or paste them into your PMS's webhook configuration). The URL is shared per tenant — the token is what tells Kiwire which connector instance and PMS type to use, so no per-connector URL segment is needed.

Authenticating the Request

Kiwire accepts the token in any one of these, checked in order:

Method	Example
HTTP header X-PMS-Token	X-PMS-Token: ObmY9HeFMYJr0vjKIIXoWzFprs4NNSz5xOjF5phA
Request body / query field token	?token=ObmY9HeFMYJr0vjKIIXoWzFprs4NNSz5xOjF5phA
Request body field tokenkey	Used by eZee's integration convention

Use the header for JSON/POST-based PMS types; use the query string form for the GET type since it can't set custom headers.

JSON Type — Payload Format

The most common choice. POST a JSON body to the webhook URL with header Content-Type: application/json:

{
  "action":         "checkin",
  "room":           "101",
  "first_name":     "John",
  "last_name":      "Doe",
  "vip_code":       "VIP123",
  "check_in_date":  "2026-08-28",
  "check_out_date": "2026-08-30"
}

Field	Required	Notes
action	Yes	checkin, checkout, or roomchange (case-insensitive)
room	Yes	Room number — must match an existing WiFi account's username
first_name / firstname	No	Either key name is accepted
last_name / lastname	No	Either key name is accepted
new_room	Only for roomchange	The room the guest is moving to
vip_code	No	Matched against configured VIP codes, if any
check_in_date / check_out_date	No	ISO 8601 or Y-m-d — used to set account expiry

Example using curl:

curl -X POST "https://your-kiwire-domain.com/pms/inbound/{tenant_id}" \
  -H "X-PMS-Token: ObmY9HeFMYJr0vjKIIXoWzFprs4NNSz5xOjF5phA" \
  -H "Content-Type: application/json" \
  -d '{"action":"checkin","room":"101","first_name":"John","last_name":"Doe"}'

Other Webhook Types

Pick one of these instead if your PMS uses a fixed integration format it can't customize:

Type	Request Format	Notes
get	Plain GET query string	Accepts several common key-name aliases for action/room/name fields — for PMS systems that can only fire a URL, not POST JSON.
idb	JSON, UPPERCASE keys (COMMAND, ROOM, GUEST, LASTNAME...)	Also supports a pull-based "DB Sync" for full reconciliation.
pro	GET query string, PascalCase (Event, Room, FirstName...)	Kiwire responds in XML — required by this integration.
ezee	JSON/form, lowercase (mode, room, fname, lname...)	No checkout-date field is ever sent by eZee.
rhealta	Form POST, short lowercase keys (fnm, lnm, ci...)	Supports up to two additional "sharer" guests per room; no room-change support.
comanche	JSON, PascalCase, single GuestName field	Also supports a pull-based "DB Sync".

Ask your Kiwire partner for the exact field list of a specific type if your vendor's integration guide doesn't spell it out clearly.

Response Format

Kiwire replies to every webhook call so the PMS can confirm delivery. The format depends on the type:

Type	Response
Default (json, get, idb*, ezee, rhealta)	200 {"success": true, "message": "..."} or 400 {"success": false, "message": "..."}
idb	[{"status": "1", "ResponseMessage": "..."}] (status: "0" on failure)
pro	XML: <PINS_APIResponse><Status ErrorCode="0"><Message>OK</Message></Status></PINS_APIResponse>
comanche	{"Status": "SUCCESS"} or {"Status": "FAIL", "ErrorCode": "...", "ErrorMessage": "..."}

A 200/success: true response only confirms the event was accepted and queued — provisioning happens asynchronously a moment later. Check PMS Transactions or the PMS Log to confirm the account was actually activated.

Socket Daemon Setup (Opera, Infor, Oasis)

These types use the FIAS protocol over a direct TCP connection — Kiwire connects out to the PMS, rather than the PMS pushing to Kiwire.

Field	Description
PMS Host	Hostname or IP of the PMS server (no http:// prefix).
PMS Port	TCP port the FIAS interface listens on — default 5010.

Use the Ping button next to the port field to check basic TCP reachability before saving. Once saved and enabled, Kiwire provisions a background daemon (managed by the process supervisor) that connects and stays connected, reconnecting automatically if the link drops. Its live status (Running / Stopped / etc.) and a Restart control appear on the connector form once saved.

Kiwire Agent Setup (Opera / Infor / Oasis — Agent)

Choose an -agent variant when Kiwire's server cannot open an outbound connection to the PMS directly — for example, the PMS sits on an isolated hotel LAN with no route to the internet. A small Windows agent runs on a machine with network access to the PMS, speaks FIAS locally, and relays parsed events to Kiwire's API over HTTPS instead.

1. Download and run the agent installer (link shown on the connector form) as Administrator on a Windows machine that can reach the PMS.
2. Generate an Admin API key under My Profile → API Keys for the agent to authenticate with.
3. Save the connector once to get its Connector ID, then paste the generated config.json snippet (server URL, API key, connector ID, PMS host/port) into the agent's local dashboard at http://localhost:7891.

Advanced Configuration — Guest Password Setting

Field	Description
Guest Password Setting	How the WiFi password is derived on check-in: room number, guest first name, last name, full name, or a fixed predefined password.
Use on First Login Only	If enabled, the derived password is only required the first time the guest connects during their stay.
Predefined Password	The fixed password used when the setting above is "Predefined".
Password Match %	Tolerance used for fuzzy name matching on login — lower values are more forgiving of typos.

Database Synchronization

The Sync DB button (shown for idb, comanche, and all socket/agent types) reconciles Kiwire's guest list against the PMS's current in-house list: every currently active PMS-provisioned account is suspended, then only the rooms the PMS reports as occupied are re-activated. Use it after any outage to clean up guests who checked out while the connection was down.

Monitoring & Troubleshooting

• PMS Log (Monitoring → PMS Log) — raw, per-hour log files of every event received, searchable by room number.
• PMS Transactions (Reporting → Delivery Log) — a structured audit trail of every check-in/check-out/room-change event and its outcome, with CSV export.

Required Permission

manage-connector-pms