PMS Connector
The PMS (Property Management System) connector integrates Kiwire with hotel PMS platforms, enabling guests to authenticate on the captive portal using their room number and last name — no separate WiFi account required. Check-in and check-out events are monitored in real time so WiFi access follows the guest's reservation automatically.
'alt' => 'Dashboard overview', 'caption' => 'The default Kiwire dashboard layout', 'screenshot' => true, 'class' => '', ]) Drop images into: public/assets/img/docs/{page}/{filename} --}}public/assets/img/docs/connector-pms/overview.png
Use Case
In hotel environments, guests expect WiFi access the moment they reach their room. The PMS connector removes the friction of a separate sign-up flow: the guest simply enters their room number and last name (or a PMS-issued guest code) on the captive portal. Kiwire queries the PMS API in real time to confirm the guest is currently checked in, then automatically creates or activates a WiFi account and grants access. No front-desk intervention is needed.
The PMS connector is typically used together with a captive portal journey configured to show the "Room & Last Name" login method. Make sure your journey includes the PMS login step.
Supported PMS Systems
| PMS System | Type Value | Notes |
|---|---|---|
| Fidelio Opera | opera | Uses Opera Web Services (OWS) SOAP API |
| Protel | protel | Uses Protel I/O HTTP API |
| Generic HTTP | generic_http | Custom REST endpoint — configure request/response field mapping |
If your PMS is not listed, use generic_http and configure the field mappings to match
your PMS's REST API response structure. Contact your Kiwire partner for assisted integration.
How It Works
The authentication flow for a hotel guest is as follows:
- Guest connects to the hotel WiFi SSID and is redirected to the Kiwire captive portal.
- Guest enters their room number and last name (or PMS guest code) on the portal login page.
- Kiwire calls the configured PMS API to check whether a guest with that name is currently checked in to that room.
- If the PMS confirms a valid reservation, Kiwire creates or reactivates a WiFi account linked to that reservation and grants network access immediately.
- If the PMS returns no match (wrong room, wrong name, already checked out), the portal displays an error and the guest is prompted to try again or contact the front desk.
public/assets/img/docs/connector-pms/flow-diagram.png
Configuration Fields
| Field | Description |
|---|---|
pms_type | Which PMS system to connect to: opera, protel, or generic_http |
api_url | Base URL of the PMS API endpoint (e.g. https://pms.hotel.com/api/v1) |
api_key | API key or Bearer token for authenticating requests to the PMS |
auth | HTTP Basic auth credentials in username:password format (used when the PMS requires Basic authentication instead of an API key) |
property_id | The hotel property identifier as configured in your PMS (required for multi-property deployments) |
timeout | Maximum time in seconds to wait for a PMS API response before returning an error to the guest (default: 10) |
Never expose the PMS API URL or credentials publicly. The Kiwire server communicates with the PMS API server-side only — guest browsers never see the PMS credentials.
Account Provisioning & Lifecycle
When a guest is verified by the PMS, Kiwire automatically provisions a WiFi account linked to their reservation:
- A WiFi account is created automatically using the guest's reservation details as the identifier.
- The account is assigned the profile configured on the PMS connector (e.g. "Hotel Guest — Standard").
- Account expiry is set to the reservation checkout date returned by the PMS.
- If the guest logs out and reconnects during the same stay, the existing account is reactivated — a new account is not created.
On guest check-out, Kiwire detects the event automatically and deactivates the corresponding WiFi account. Any active RADIUS sessions are disconnected via a CoA (Change of Authorization) packet sent to the NAS.
The auto-deactivation on check-out relies on the PMS daemon receiving checkout events. If your PMS does not support push notifications, Kiwire falls back to polling the PMS API every few minutes for reservation status changes.
PMS Daemon
Kiwire runs a dedicated background process managed by the process supervisor. This daemon maintains a persistent connection (or polling loop) to the PMS system to receive real-time check-in and check-out events. It is separate from the main queue workers to ensure PMS events are processed promptly regardless of general queue load.
Check the daemon status from your server's process manager. Your system administrator can view daemon logs in the application's log directory.
'alt' => 'Dashboard overview', 'caption' => 'The default Kiwire dashboard layout', 'screenshot' => true, 'class' => '', ]) Drop images into: public/assets/img/docs/{page}/{filename} --}}public/assets/img/docs/connector-pms/daemon-status.png
Testing the Connection
After saving the connector configuration, use the Test Connection button to send a sample request to the PMS API. Kiwire will attempt to look up a known room number and display the raw API response so you can confirm the integration is working before going live.
Ask your PMS vendor for a test reservation or sandbox environment to validate the Kiwire integration without affecting live guest data.
Required Permissions
view-connector-pms · edit-connector-pms