Hotel PMS and Hotspot Integration: Connecting Wi-Fi to Your Property Management System
In short: what is hotel PMS and hotspot integration?
Hotel PMS and hotspot integration means that the software managing the hotel's reservation and stay data (the PMS – Property Management System) and the hotspot system managing guest Wi-Fi access exchange data with each other. This allows guests to connect to Wi-Fi with details such as their room number and surname; the system verifies against the PMS that the guest is actually staying, and can automatically end access after check-out. Whether integration is possible and how it will work depends on the API or interface method offered by the PMS and the support provided by the hotspot software.
What is a hotel property management system (PMS)?
A property management system is the central software that runs processes such as reservations, room management, check-in, check-out, guest records, folios and payments, housekeeping, channel management and reporting. Almost every department of a hotel, from reception and accounting to housekeeping and sales, works with this system. The "single source of truth" for the guest's stay lives in the PMS: who is staying in which room, the arrival and departure dates, and which room type and package the guest has booked.
The hotspot system, meanwhile, manages guests' internet access. When these two systems work in isolation, Wi-Fi access becomes disconnected from the stay: reception generates a separate code for each guest, access may continue after the guest leaves, or connection problems appear when a guest changes rooms.
Why does integration matter?
Guest experience
Guests do not have to look for an extra password or code to connect to Wi-Fi. They connect in seconds using details they already know, such as room number and surname. This is a real convenience, especially for guests arriving late or not wanting to queue at reception.
Operational efficiency
Reception staff spend less time generating vouchers, sharing passwords or answering Wi-Fi questions. Access opens and closes automatically based on the stay record.
Security and control
The access of guests who have checked out is terminated, preventing people who have left the hotel, or who learned the password from others, from using the network. Access records become consistent with stay data.
Revenue and personalisation
Different speed profiles can be defined by room type or package. For example, suite guests can be given higher speeds, a guest in a standard room can be offered a paid premium package, and the cost of a purchased package can be posted to the PMS folio (this last feature depends on the scope of the integration).
Integration methods
Data exchange between a PMS and a hotspot system can be set up with different technical methods:
REST or SOAP API
Most modern property management systems offer web services through which external systems can query reservation and guest data. When the guest enters details on the portal, the hotspot system sends a query to this service and gets an answer to the question "is there an active stay in this room under this surname?". This is the most common and flexible method.
Event-based notifications (webhooks)
Some PMSs can send instant notifications to external systems when events such as check-in, check-out or a room change occur. This method is ideal for scenarios such as closing access immediately at check-out.
Interface protocols and middleware
Some PMSs used by large hotel chains communicate with third-party systems (telephone exchange, TV, door locks, Wi-Fi) through their own interface protocols. In this case an intermediate layer or interface licence may be needed instead of a direct integration.
Database queries or file transfer
In older setups, read-only access to specific tables in the PMS database or periodic file transfers may be used. These methods should be carefully assessed for security and timeliness.
How should the data flow be designed?
For an integration to work reliably, it must be clear which data is transferred, in which direction and when.
Information the hotspot may need from the PMS:
- Room number
- Guest surname (and, if required, date of birth or reservation number)
- Stay start and end dates
- Stay status (active, checked out, cancelled)
- Room type or package (for the speed profile)
- Number of guests in the room (for the device limit)
Information that may be sent back to the PMS (optional):
- Premium internet package purchased and its price
- Summary information about the guest's Wi-Fi use
Under the principle of data minimisation, only the fields needed for authentication and policy should be transferred to the hotspot system. Data such as the guest's passport details or payment information is not needed for Wi-Fi authentication.
Real-world scenarios that must be addressed
Most integration projects work smoothly in the ideal scenario; problems appear in the exceptions. The following situations must be designed at the start of the project:
- Early arrival: What happens if the guest wants to use the internet in the lobby before the official check-in time?
- Late departure: The check-out has been recorded but the guest is waiting in the lobby for a transfer; will extra time be given?
- Extended stay: When the departure date changes, is the session time on the hotspot side updated automatically?
- Room change: When the guest moves to another room, what happens to sessions opened with the old room details?
- Several guests in one room: Can guests with different surnames connect? How will the per-room device limit be applied?
- Cancellation or no-show: Is access closed when the booking is cancelled?
- Group and agency bookings: How will the guest surname be verified for rooms booked under a group name?
- Connection outage: How will the hotspot behave when the PMS cannot be reached? If a guest cannot connect, which alternative method (such as a voucher) will reception use?
- Special characters and spelling differences: Differences such as "Öztürk" vs "Ozturk" must not cause authentication problems.
Example flow: integrated Wi-Fi from the guest's perspective
Imagine a business traveller arriving at the hotel at 11:40 pm. Check-in is completed at reception and the stay becomes "active" in the PMS. When the guest goes to their room and connects their phone to the guest network, the captive portal opens automatically. The screen shows the hotel's logo, a welcome message in the device's language and two fields: room number and surname. The guest enters the details; within seconds the hotspot system queries the PMS, confirms that there is an active stay in this room under this surname and opens internet access with the speed profile defined for the room type.
The next day, when the guest wants to connect their laptop too, they log in with the same details; since the per-room device limit has not been exceeded, the second device connects as well. When the guest extends their stay by a day, reception enters the change in the PMS and the hotspot session time is extended automatically. On departure day, once the bill is settled, access ends after a short grace period set by the hotel. Throughout the stay the guest never had to ask for a password, and reception did not perform a single Wi-Fi-related task.
Questions to ask your PMS vendor
- Is there an API through which external systems can query guest and stay information? Can the documentation be shared?
- Is an additional licence, module or fee required to access the API?
- Is there support for instant notifications (webhooks) for events such as check-in, check-out and room changes?
- Can a test environment (sandbox) be provided?
- Can the integration account's permissions be limited to the required fields only?
- Is a query count or rate limit applied?
- Are API changes announced in advance when the system is updated?
- Is it cloud-based or running on an on-site server? How will the hotspot server reach it?
Security and KVKK considerations
The PMS holds the hotel's most critical data. Security must therefore be a priority in integration design:
- The hotspot system should be given a limited integration account in the PMS that can read only the required data.
- Communication should take place over encrypted (HTTPS/TLS) channels, and API keys should be stored securely.
- The PMS server should not be directly reachable from the guest network; integration traffic should flow only between the hotspot server and the PMS, restricted by firewall rules.
- A privacy notice should be provided under KVKK for the personal data transferred, and the processing purpose and retention period should be defined.
- Integration errors and access attempts should be logged.
Integration project steps
- Needs analysis: Which scenarios should be automated? Room number login, closing access at check-out, posting paid packages to the folio?
- Feasibility check: Request API documentation and integration terms (licence, fee, access method) from the PMS vendor, and confirm that the hotspot software supports this method.
- Data mapping: Map field names, date formats, room number structures and status codes between the two systems.
- Test environment: Where possible, try scenarios in a test environment without touching the live system.
- Scenario testing: Test all the exceptions listed above with real data.
- Pilot: Run the integration for a set period in a limited number of rooms and collect feedback from reception.
- Go-live and monitoring: Set up an alert mechanism for integration errors and monitor closely during the first weeks.
- Documentation and training: Reception staff should know the alternative procedure to apply when the integration is not working.
Common mistakes
- !Assuming integration will "just work" without talking to the PMS vendor.
- !Testing only the ideal scenario and ignoring exceptions.
- !Connecting to the PMS with a broadly privileged or administrator account.
- !Guests being unable to connect when the integration fails, with no alternative method available.
- !Not accounting for special characters and case sensitivity.
Frequently asked questions
Can every hotel PMS be integrated with a hotspot?
No. Integration depends on whether the PMS makes data available to external systems and under what conditions. Some PMSs offer an open API, while others require an additional licence or middleware.
Does the hotel have to pay extra for integration?
That depends on the commercial terms of the PMS vendor and the hotspot provider. Some PMS vendors may charge a licence fee per interface. This should be clarified at the start of the project.
Is room number login possible without integration?
Technically, a similar experience can be achieved with manual lists or vouchers, but it will not be as reliable as automatic integration in terms of verification, closing access after check-out and keeping data up to date.
Can guests connect when the PMS is down?
That depends on how the system is designed. A good design includes an alternative authentication method (for example a voucher issued at reception) that takes over when the PMS cannot be reached.
Does integration copy guest data into the hotspot system?
That depends on the method used. In query-based setups, the hotspot system only asks the PMS at the moment of authentication and uses the result; it permanently stores only the information needed for session and access records. Which data is kept and for how long should be determined by the retention and destruction policy under KVKK.
How long does integration take?
If the PMS has a ready-made interface and the hotspot software supports it, the process can be short. Where new development is required, the timeline can be longer once testing and pilot phases are included.
Next step with Richspot
Richspot Hotspot is designed to support hotel scenarios such as room number login and authorisation based on check-in/check-out times, and more advanced integrations with hotel PMS software are also on the product roadmap. Evaluate Richspot's integration compatibility with your PMS using the API documentation. Clarify the scope of the Boutique Hotel and Hotel packages and the integration requirements with the Richspot team at the start of the project.
