We read the in-house list out of OPERA Cloud through Oracle's Hospitality Integration Platform, and a guest signs in with their room number and surname. This is the most demanding connection on the list to set up and the least forgiving of a wrong value, so it is worth reading the requirements before you start.
Oracle OPERA Cloud is the property's own system. We connect to it; it is their product, not ours. oracle.com/hospitality ↗
On the interval you set — five minutes out of the box — we ask OHIP for the reservations currently occupying a room at your property, and that answer becomes the list the sign-in page checks against. A guest checked in at ten past is signing in by quarter past.
It is a poll rather than a live feed, because that is how OHIP works. Set the interval to a minute if a minute matters to you.
The one thing to know about OHIP is that it layers two credentials which are easy to confuse. An application key identifies our integration to Oracle, and an OAuth client buys a bearer token for each call. Both are required every time, and sending only the token fails as an authorisation error that reads exactly like a bad password.
This system is asked rather than telling us — every five minutes out of the box, and as often as every minute if you want.
No rates, no folio, no card details and no passport numbers. Those belong at the front desk, not in a Wi-Fi portal.
A guest types their room number and their surname, and they are online. Nothing else is asked: no email, no form, no questions. Access ends at checkout plus the property's grace period, and wrong answers are cut off after five tries.
That is deliberate, and it is the whole argument for connecting a front-desk system at all. Your guest stood at your desk an hour ago and showed a passport. Asking them to prove themselves again to a web page, with an email address and a consent box, is an insult with a spinner on it. The details you learn about that guest come from the system that already knows them, and every session ties back to the booking you already hold.
A short list, and worth reading before you start.
What it costs. Carried by the Hotel plan, which includes one front-desk connection. What each plan includes →
Connecting Oracle OPERA Cloud tells us who is staying. Your Wi-Fi equipment is what actually holds a guest at the sign-in page and lets them through afterwards — and whether a checkout can take somebody offline immediately depends on the make.
Forty makes, each with what it can do, what has to be true first, and whether checkout ends a session or the session runs to its time limit. The kit most hotels run: Aruba, Ruckus SmartZone, Cisco Meraki, Juniper Mist, Ubiquiti UniFi, TP-Link Omada, MikroTik, and the hotel gateways Nomadix and Antlabs InnGate.
What happens between a guest joining the Wi-Fi and reaching your welcome page, in plain English, with the technical section for whoever looks after the network.
The other front-desk systems, the Wi-Fi makes, the mailing tools and the CRMs — and the route for a system that will never have a named connector of its own.
Sign in with their room number and surname, checked against the in-house list held in Oracle OPERA Cloud, and stay connected until they check out plus the grace period you set. No password, no email, no form.
Within a few minutes. Oracle OPERA Cloud is asked on a schedule the property sets, five minutes by default, so a guest who checked in a moment ago may wait for the next check.
The in-house list: room number, surname, the reservation, as Oracle's own identifier, departure date, nationality and language, where held. No rates, no folio, no card details and no passport numbers.
Carried by the Hotel plan, which includes one front-desk connection.
How many rooms, what Wi-Fi equipment is in the building, and whether anybody on site looks after the network. That is enough for a straight answer.
