Hotel AI That Connects to Oracle OPERA PMS: How OHIP Works

Hotel AI guest messaging connects to the Oracle OPERA PMS, in its OPERA Cloud form, through the Oracle Hospitality Integration Platform (OHIP). The vendor registers an application, the hotel creates and its chain administrator approves an integration user, the tool reads reservations through REST APIs and listens for business events such as check-in and check-out, and every call is metered on a pay-as-you-go subscription with 10,000 transactions included each month. That is what "we integrate with Opera" means when it is true. It also means three follow-up questions: which OPERA, through what, and who pays for the calls. This piece answers them from Oracle's documentation; our guide to PMS and AI integrations covers the wider field.

Everything here reflects Oracle's OHIP documentation as read in October 2026. Oracle changes prerequisites and pricing, so confirm the current text before you approve anything.

What is OHIP, and which OPERA does it cover?

OHIP is the gateway between OPERA Cloud and everything that is not OPERA Cloud. Oracle's user guide describes it as the Oracle Hospitality Developer Portal plus the Hospitality REST APIs, with a workflow of discover the APIs, register an application, then register the APIs to that application ^[1]. The release notes add the pieces a vendor works with: an OAuth API that issues JWT tokens, an Integration Processor API that exposes business events, and versioned REST modules ^[3]. Oracle positions it as self-service tooling for partners building on OPERA Cloud, and cites more than 73,000 implementations and 5.2 million rooms across its hospitality business, Oracle's own figures ^[4].

The scope line matters more than the feature list. Oracle's FAQ states that the customer must be running OPERA Cloud with an active subscription for OPERA Cloud Foundation or OPERA Cloud Central ^[2]. On-premise OPERA 5 is not that. If your property runs OPERA 5 on a server in a closet, a vendor who says "we integrate with Opera" is describing a different interface or has not asked which version you run. Ask Oracle what is available for your version, and do not sign until you know.

Integration layers for an OPERA Cloud property, from Oracle's OHIP User Guide and FAQs, accessed October 2026.

What does a vendor have to do before it can touch your OPERA Cloud?

More than fill in a form, and each step is a question you can ask. Oracle's FAQ lays out the production path. The partner must list in the Oracle Hospitality Cloud Marketplace under the OHIP category, which requires Oracle Partner Network membership. The partner then emails the listing ID to Oracle's hospitality integrations team to be granted production access. The hotel creates an integration user in its production tenancy, and the customer chain administrator approves that user ^[2]. Application keys, per the release notes, access both production and non-production environments ^[3].

So when a vendor says they are "Opera certified," the verifiable version is: a Marketplace listing under the OHIP category, with a listing ID, that you can look up. Before that exists, development happens in shared partner sandboxes that Oracle describes as shared across more than 1,300 companies and 5,000 developers ^[2], which is fine for building and not a place your guest data should ever be.

The chain administrator approval is the hotel's lever. At a group, that person may sit at corporate, and the approval has a policy behind it. Find out who it is and what they require before the vendor's form lands, because it will land, and "we are waiting on your chain admin" is a sentence nobody enjoys hearing in week six.

What data flows from OPERA Cloud to a messaging tool?

A narrow slice, if the vendor is disciplined. The release notes list operation counts by module in the first versioned release: Reservation 25, Housekeeping 8, Front Desk Operations 3, CRM 6, Rate 3 ^[3]. For guest messaging, the Reservation module does almost all the work: arrival and departure dates, room, guest name and reservation status. Business events, exposed through the Integration Processor API, tell the tool that a check-in or check-out happened without the tool asking ^[3].

Guest messaging moments mapped to OPERA Cloud sources, from Oracle OHIP release notes, accessed October 2026. Which reads a vendor supports varies; ask for the exact operations.

Notice the middle row. The Wi-Fi code, dinner hours and pool policy do not come from OPERA. They come from the property's own knowledge base, and no API call is spent answering them. The Housekeeping and Front Desk Operations modules matter only if the tool writes back, for example syncing a towel request into OPERA's task list, and that is a later step for most properties. How the same slice works on Apaleo's open API is an instructive contrast: same data, different access model, different cost.

Polling or streaming: how does the tool know a guest checked in?

Two mechanisms, and the choice is about latency and cost. With polling, the vendor's application asks OHIP for new business events on a schedule. Oracle's FAQ states that polling retains events for 48 hours and returns a maximum of 20 events per call ^[2]. With streaming, events are pushed continuously; Oracle retains streamed messages for seven days, and streaming requires OPERA Cloud Foundation 22.3.0.1 or later plus engagement with Oracle Professional Services ^[2].

Source: Oracle Hospitality Integration Platform User Guide FAQs, accessed October 2026. Prerequisites and retention are Oracle's and may change.

For a welcome message, the difference between a 15 minute poll and a streamed event is 15 minutes, which is fine. For a tool that wants to greet a guest the moment the key is cut, it is not. The trade is that every poll is a billed call whether or not anything happened, and streaming carries a version prerequisite and a services engagement. Ask the vendor which they use, at what interval, and have them show you the arithmetic in the next section with your room count in it.

What does OHIP cost to call?

It is a cost line, and it belongs in the contract. Oracle's FAQ describes OHIP as available only through a paid subscription under a pay-as-you-go model, with 10,000 transactions included per monthly billing cycle and additional calls billed at approximately USD 20 per 10,000 calls, or proportionally for fewer ^[2]. Usage is billed in sandbox, non-production and production environments. Calls that fail with 429, 500, 502, 503 or 504 errors are not charged ^[2].

Illustrative, with the arithmetic shown so you can swap in your numbers. A 200 room hotel whose vendor polls for business events every 15 minutes makes four calls an hour, 96 a day, about 2,880 a month, before it reads a single reservation. Call it 2,900. Now add reads: at 70% occupancy and an average stay of two and a half nights, that hotel has roughly 56 arrivals a day, or about 1,700 reservation reads a month if the tool reads each arrival once. Total: about 4,600 transactions, inside the 10,000 included. Change the poll to every five minutes and the polling alone is about 8,600; add the reads and the hotel is paying overage at roughly USD 20 per extra 10,000, which is small money but someone's money, and the point is to know whose.

That is the question for the contract: who owns the OHIP subscription, and who pays overage? If the hotel does, the vendor's polling interval is spending the hotel's budget. If the vendor does, ask how that is priced into the license. Either answer is fine. Not knowing is not.

Does hotel AI need the OPERA PMS integration on day one?

No, for most of the daily value, and the research on integration is a reason to sequence rather than wait. In Starfleet Research's 2025 survey of more than 250 hotel IT decision makers, underwritten by IBS Software, 24% said their core systems were fully integrated and 42% relied on disconnected systems for guest data ^[6]. In the NYU Tisch Center's 2026 outlook, sponsored by Stayntouch and IDeaS, 38% of more than 300 hotel professionals named integration a top pain point, while 68% of independents with 101 or more rooms ran multi-vendor stacks ^[5]. Both are vendor-sponsored; both point the same way. Integration is slow and most hotels are not finished with it.

A guest messaging layer that waits for OHIP waits a long time. What runs without it: property Q&A, service requests with owners, one inbox across channels, sentiment flags and escalation, all with the guest identified by QR code or stay link. What needs it: messages triggered by reservation events and accurate "what do I owe" answers. Whether AI messaging needs a PMS integration on day one goes through the full split.

The sequencing I would argue for at an OPERA Cloud property is standalone first, then scope the connector against the metering math above. The one rule for the standalone phase is that the new tool must replace inboxes, not add one, or it becomes another instance of hotel tech fragmentation with a nicer interface.

What should be on the hotel's readiness checklist?

Ten items, before you say yes to the integration request in your inbox.

1. Which OPERA edition and version you run (Cloud Foundation, Cloud Central, or on-premise OPERA 5), confirmed in writing by whoever owns the Oracle relationship.
2. Who your chain administrator is and what their approval policy requires.
3. Your integration user policy: naming, least privilege, review cadence, revocation.
4. Whether the vendor will work in your non-production environment before production, and who provisions it.
5. Who owns the OHIP subscription and who pays overage, with the vendor's polling interval or streaming choice stated.
6. The exact API operations the vendor will call and the business events it will consume.
7. Whether anything is written back to OPERA, and if so, what and under whose approval.
8. The vendor's Marketplace listing ID under the OHIP category, and its date.
9. Data retention and deletion terms for anything the vendor stores from OPERA, in days.
10. What the tool does when OHIP is unavailable, and how the hotel will know.

Several of these are the same questions you would put to any vendor, and questions to ask any hotel software vendor carries the full list with the answers that should worry you. The OPERA-specific ones are 1, 2, 5 and 8, and they are the ones most often skipped because the demo was good.

Where ResortConcierge helps

The practice above is standalone first, then a narrow, metered connector. ResortConcierge AI runs without a PMS today: QR or stay link entry, a property knowledge base and one inbox for SMS, WhatsApp, email and web chat need no OPERA connection, so an OPERA Cloud property can start while the OHIP work is scoped.

The operational object an OPERA Housekeeping write would eventually sync to already exists: service requests with status and an owner live in the platform today and the team works them there.

The OPERA connector itself is planned, not shipped; the OPERA integration page, where connector status is published, is where that changes, and nothing in this post should be read as implying an Oracle Marketplace listing, OHIP registration or certification.

Pull up the integration request form and read it against the ten items. If you cannot answer items 1, 2 and 5 from your own records, the form can wait a week while you find out, and that week will be cheaper than the alternative. For what it is worth, I plan family trips with a spreadsheet, and even I think the metering math belongs in the contract rather than in anyone's head.