Cloudbeds, Mews and Opera APIs: what a real integration involves
Each one documents a real API. None of them lets you start with a key and a docs page. Access runs through a partner process first, then through an admin at every property you connect.
Answered in short
4 things that decide this
- 01Cloudbeds runs a public developer portal and a Marketplace. Its docs say the partnerships team reviews an integration before you get to build and certify it. API keys are the preferred way to sign in, with OAuth 2.0 written up as an alternative. The published rate limit is 10 requests per second.
- 02Mews calls its whole platform the Mews Open API. The Connector API is the general-purpose piece inside it, next to the POS, Booking Engine, Channel Manager and Loyalty APIs. Requests carry a ClientToken for your integration and an AccessToken for the property. You get a permanent live ClientToken once you pass certification.
- 03Oracle OPERA Cloud is reached through the Oracle Hospitality Integration Platform. Oracle's docs say OPERA Cloud resources are only available that way for OPERA Cloud Foundation customers. You need a paid Oracle Hospitality Integration Cloud Service plan first. Calls use OAuth 2.0 client credentials plus an app key in an x-app-key header.
- 04All three approve you per property, not once. A Cloudbeds property connects your app from the Marketplace and confirms the scopes. Mews issues a separate AccessToken for each property. With OPERA, you request a connection in one portal and the hotel approves it in another.
The gate is a person, not the code
Ask whether a PMS "has an API" and all three say yes. That's why the question rarely tells you how a project will go. Each one publishes docs you can read today. None of them lets you sign up, take a key and start writing against a live property the same afternoon.
What sits in the way is a person, and it happens twice. First the vendor decides whether your integration should exist at all: a partnerships review at Cloudbeds, certification at Mews, or a paid plan and account activation at Oracle. Then each hotel decides whether you may touch its data. That approval is per property, not per integration.
So the question that matters isn't whether the endpoint you need exists. It's whether you're already through the partner process, and whether the property's own admin is free and willing to click approve. That's calendar time, not engineering time.
A public portal, a Marketplace, and a partnerships review before certification
Cloudbeds publishes its developer docs openly, so you can read the API reference before you commit to anything. Partner onboarding is written up as a five-step path. Cloudbeds says plainly that its partnerships team must review your integration before you move on to build and certify it.
On signing in, the docs name API keys as the preferred method. OAuth 2.0 authorization code flow is written up as an alternative that's still supported. With OAuth, the access token lasts eight hours and the refresh token extends each time you use it. Published rate limits sit at 10 requests per second across endpoints. Design around that rather than finding it under load.
A property connects you from the Marketplace itself. Their user finds your app, clicks connect, and confirms the permission scopes on a consent screen. Only then is an API key issued. A sandbox exists, but you request it through the partner process rather than open it yourself, so plan testing in rather than assume it.
One platform, several APIs, and a token for every property
Getting the names right changes how you read the docs. Mews Open API is the umbrella name for the whole platform. Inside it sits the Connector API, the general-purpose piece, next to the POS API, the Booking Engine, the Channel Manager API and a Loyalty Partner API. There's no separate "Open API" sitting against the Connector API.
Signing in uses three values, not one. A ClientToken names your integration. An AccessToken names the link to one property, which Mews calls an enterprise. A Client value names your app and its version. Mews issues a fresh AccessToken for each new property on your connection, and that's what makes it per-property in practice. Certification comes before you go live, and the permanent live ClientToken follows it.
Mews is the easiest of the three to test against. Its Demo setup publishes working test logins right in the docs. Mews warns there that the demo setups are completely public and no real data should go in them. Published rate limits sit at 200 requests per AccessToken every 30 seconds, in demo and live alike. You're expected to handle a 429 response and honour Retry-After.
A paid platform subscription, then a two-portal approval with the hotel
OPERA Cloud is reached through the Oracle Hospitality Integration Platform. Oracle's docs are explicit: OPERA Cloud resources are only available that way where the hotel company is on OPERA Cloud Foundation. Most estimates miss this step, because it isn't a developer signup.
Getting in needs a paid Oracle Hospitality Integration Cloud Service plan, bought through the Oracle Store or a partner form. Then comes a cloud account activation, which the docs say must finish before anything can be set up. Signing in is OAuth 2.0 client credentials, with an app key in an x-app-key header on every request. Oracle publishes its limits in unusual detail, including a gateway ceiling of 50 requests per second shared across everyone using it.
Property approval here is the most formal of the three. You request the connection in the partner developer portal. Your hotel approves it in the customer developer portal, and an email goes to the chain admins when the request lands. Oracle tells those admins to review the modules asked for and confirm the partner really needs that access, with extra care where sensitive data is involved. A partner sandbox exists, reached after onboarding rather than on your own.
The access model, as each vendor documents it
Everything here comes from each vendor's own developer docs, checked on the date this page was last verified. Your account, your plan and your modules decide what you actually get. That's why we check it in the audit rather than promise up front.
| Platform | How you get in | Authentication | Per-property approval | Published rate limit |
|---|---|---|---|---|
| Cloudbeds | Public developer portal, then a partnerships evaluation before development and certification | API keys preferred; OAuth 2.0 documented as an alternative | Property connects the app from the Marketplace and confirms scopes | 10 requests per second |
| Mews | Public docs and a public demo environment; certification before production | ClientToken plus a per-property AccessToken | A unique AccessToken is issued for each enterprise | 200 requests per AccessToken per 30 seconds |
| Oracle OPERA Cloud | Paid Oracle Hospitality Integration Cloud Service subscription, then account activation | OAuth 2.0 client credentials plus an x-app-key header | Partner requests in one portal; the hotel approves in another | 50 requests per second per gateway, shared |
What we do before quoting a PMS integration
We scope the route into your PMS before we quote. An honest number depends on facts nobody can know from outside: which platform, which plan, which modules, and whether your account exposes the endpoints the build needs. That's a short piece of work at the start of the audit, not a discovery phase you pay for.
Then we design to what's really there. Where an endpoint gives us the booking, the guest profile or the room status, we read and write it directly. Where it doesn't, we build a queue your team accepts with one click. That's slower than an API and far better than somebody re-keying at night audit. Both are real answers. Pretending the first one is always there is not.
- 01Confirm the platform, plan and modules, and what your account exposes, before any number is quoted.
- 02Design write-back to the depth that actually exists, and put a reviewed queue where it stops.
- 03Watch the shape of what we read, so a platform update reaches you as an alert instead of a wrong number.
Some of the systems we have shipped
Related questions
01Which of the three is easiest to build against?+
Mews is the easiest to start on. Its demo setup publishes working test logins in the docs, so you can call the API before anybody approves anything. Cloudbeds is easy to read but keeps its sandbox behind the partner process. Oracle is the heaviest: access starts with a paid plan and an account activation before a sandbox appears. Easy to start isn't the same as right for you, though. Whichever one your property already runs is the right platform for you.
02Can you use our existing PMS credentials instead of your own?+
No, and that's the right answer even where it looks possible. These platforms issue logins per property, and they expect the integration itself to be a registered, reviewed party. That's what the partnerships review, the certification step and the two-portal approval are for. Building on borrowed logins puts your data outside the model the vendor designed, and leaves you no clean way to cut access off.
03How long does approval take?+
None of the three publishes a timeline, and it leans as much on your own admin's free time as on the vendor. What you can plan for is that it's calendar time, not engineering time. So start it early and run it alongside the design work rather than behind it. Any vendor quoting a firm approval date is quoting something they don't control.
04What happens where the API doesn't cover what we need?+
A reviewed queue, which is the honest fallback and a good one. Your team gets a short list to accept with one click, instead of re-typing a booking or a folio line at night audit. That record still lands in your PMS. Most properties find one or two places where this is the answer, and it beats a build that quietly stops short.
05Do we need to be on a particular plan?+
Often yes, and it's the first thing to check rather than the last. What each platform exposes varies by plan and by module. Two hotels on the same PMS can have genuinely different options. We check what your own account exposes in the audit, which is why we scope the route into your PMS before quoting anything.
Related
- Custom hotel software →PMS and accounting integration, multi-property operations and the owner's numbers.
- Hotels →The whole chain for a property, built around your PMS.
- AI guest desk →What the integration is usually for: the call answered and the booking written back.
- How to win back direct bookings from OTAs →What stay history and source reporting are worth once you can read them.
- AI, automation and custom software for hospitality →Which page owns each part of the guest chain.
- Custom software development →How we build the systems your platform won't.
