A versioned, OAuth-secured booking API: what each word means for a hotel
Versioned, OAuth-secured, and signed describe specific security and stability features. Learn what each word means for your hotel and what to ask vendors.
Contents
Key takeaways
- The word API only says a door exists; versioned, OAuth-secured and signed say how that door is fitted, and those are the words a hotel is really buying.
- A version number is a promise about process: an old shape of the connection keeps working while partners move, and someone publishes the date it stops.
- OAuth replaces one shared password with a per-partner permission that covers named actions, expires, and can be withdrawn without disturbing anyone else.
- A signature proves where a message came from and that it was not altered; it says nothing about whether the price inside it is right.
- AI Otel's partner API is built, and no partner is connected yet.
An API is a fixed way for two software systems to talk. Versioned means the hotel's software can change without breaking a connected partner. OAuth-secured means a limited, revocable permission instead of a shared password. Signed booking events let the receiver check that a message is genuine. AI Otel's partner API is built; no partner is connected yet.
A vendor brochure says its hotel booking API is versioned and OAuth-secured, and most hotel owners read past the sentence. Each of those words names a specific failure the vendor has, or has not, designed against. Each one is also checkable in a meeting: you can ask a question about it and judge the answer. After reading this piece you will be able to take that sentence apart word by word, and know what to ask before any partner is connected.
What is a hotel booking API, in one paragraph?
An API is a fixed, documented way for two software systems to exchange requests and answers, with no person copying data between screens. The hotel's system holds the room inventory, rates and bookings. A partner's system asks it questions and sends reservations. The API is the agreed list of questions that partner is allowed to ask.
The noun matters less than the adjectives. API says a door exists; versioned, OAuth-secured and signed describe how the door is fitted and who holds a key. An API is not a screen for staff, and not a channel manager by itself. It is also not evidence that any partner is connected to it.
That last point is the quiet one. An API is the place where a booking can be lost, duplicated or invented, which is why the technical sentence deserves ten minutes of an owner's attention. For plain-words background on what APIs do inside a hotel generally, see Hotel PMS integrations explained: APIs in plain words; this article stays on the three adjectives.
What does versioned mean for a hotel's connected partners?
Versioned means the API carries a version number, so a change can be introduced without silently breaking the partners already connected to the older shape. The version number is a small thing that buys time: the old shape keeps answering while partners move across, and the vendor publishes the date it will stop answering.
Separate two kinds of change. Adding an optional field is additive and usually harmless. Renaming a field, removing one, or changing what a field means breaks any partner that reads it.
| Change | What the connected partner sees | What happens if nobody versioned it |
|---|---|---|
| A new optional field is added | Nothing changes; the partner can ignore the new field | Usually harmless, unless the partner rejects unknown fields |
| A field is renamed | The partner must be updated before the change takes effect | The partner reads an empty value and stops working silently |
| A field is removed | The partner's request or reading breaks on that field | Bookings stop arriving with no error on the hotel's side |
| A field's meaning changes, for example a rate now includes tax | The partner must be told and adjust its own logic | Prices are silently wrong on one side of the connection |
| A new field becomes mandatory | The partner must start sending it to keep working | The partner's requests are refused and it may not know why |
The hotel's exposure is quiet. A broken partner does not send a complaint; new bookings simply stop arriving and the room sits unsold while the calendar still looks normal. So ask three questions: how many versions run at the same time, how much notice an old one gets before retirement, and who is responsible for telling the partner.
Versioning is a promise about process, not a guarantee of quality. A vendor can version carelessly, retire a version early, or forget to tell anyone. The same question exists in older formats: tour operator and bedbank connections over file-based links raise identical issues of notice and compatibility, covered in XML connections with tour operators and bedbanks: what a hotel agrees to.
What does OAuth mean in plain words?
OAuth is a way to give a partner a limited permission instead of your password: the partner gets its own credential, good for named actions, that you can withdraw. The shared-password problem is not that the password is weak. It is that one secret opens everything, leaves no record of which partner did what, and cannot be changed without breaking every partner at once.
Under OAuth the partner has its own identity and a scope, which is the list of actions it may take: read availability, create a booking, cancel one. Anything outside the scope is refused. The permission is carried by a token, a short string that stands for the permission and expires, after which the partner must obtain a fresh one.
Revocation becomes a single act: withdraw that partner's permission and the rest keep working, with no password circulated to anyone. Each request is attributable to one partner, which is what makes the question "who cancelled this booking" answerable at all.
Be clear about what OAuth does not do. It does not by itself encrypt the hotel's data in transit, it does not make a careless partner careful, and it does not replace a contract or a named contact.
Key pointOAuth answers the access question, not the trust question
OAuth says what a partner may do and how to end it. It does not say whether that partner should have access at all; that stays a management and contract decision the hotel makes before any credential is issued.
What is a signed booking event, and how does the receiver check it?
An event is an automatic message one system sends another when something happens, and a signature is a short code computed from the message and a secret both sides hold, so the receiver can tell the message came from the sender and was not altered on the way.
Events replace polling. Without them the partner asks every few minutes whether anything is new. With them the hotel's system tells the partner the moment a booking is created, changed or cancelled. The failure they prevent is concrete: a forged cancellation that quietly frees a room, or a forged confirmation that puts a guest in front of a reception desk for a booking that never existed.
The check is mechanical. The receiver recomputes the code from the message it received and the secret it holds, compares the two, and rejects the message if they differ. Replay needs its own guard: a genuine message captured and sent again later must be refused, usually by rejecting old timestamps or repeated identifiers.
Signing covers origin and integrity only. A correctly signed message with a wrong rate is still wrong, and a partner that mishandles a valid message after receiving it is outside the signature's reach. So ask what exactly is signed, whether the secret is unique per partner, how the secret is rotated, and what the receiver does with a message that fails the check.
Watch outA signature proves origin, not correctness
A signature proves where a message came from and that nobody edited it. It does not prove the content is correct. If the price inside a properly signed message is wrong, the signature will not save the booking, so the hotel still needs a reconciliation step.
What does AI Otel's partner API actually claim?
The claim is deliberately narrow: partners and AI assistants connect through a versioned, OAuth-secured booking API and receive signed booking events. It is built, and no partner is connected yet. Built is a status word with a fixed meaning here: working software, ahead of launch, not in customers' hands. It is not the same as operating with partners, and no agency, booking site or partner is connected to it today.
The same door is meant to serve a partner's system and an AI assistant acting for a traveler, within limits the hotel sets. That is the point of defining each hotel action once in a shared core, described in AI Otel Core: how hotel teams, partners and AI share one system. The three adjectives sit in the sentence because they describe what a connection would rest on: a version policy, a per-partner permission, and a checkable message.
Read it as a design statement with a status attached, not as a customer list. The sentence does not name partners, does not count connections, does not claim a certification, and says nothing about how a person signs in to the hotel's own system.
What does the hotel still decide, whatever the API does?
The hotel decides who connects, to which actions, for how long, and how the access ends; the API only makes those decisions enforceable. Before connecting anyone: name the partner, list the actions it actually needs, and state which room types and rate plans are in scope. A permission wider than the job is a decision nobody made on purpose.
During the connection: keep a named contact on both sides, a way to see what the partner did, and a rule for who may approve an expanded scope later. Ending it: agree the exit in writing, withdraw the permission on the day, and confirm what happens to the guest data the partner already holds.
Contract points worth insisting on: notice before an API version changes, who tells whom when a connection fails, and who carries the cost of a double booking caused by a partner's error. The hotel's own staff access raises the same questions of scope, revocation and record, and is worth reviewing with the same checklist; see Who can reach your hotel systems? A review of vendor remote access, integrations and API keys.
ChecklistBefore any credential is issued, a hotel should be able to answer these in writing
- Who approves a new partner
- Which actions that partner may take
- How long the permission lasts before renewal
- Who can withdraw it, and how quickly
- Where the partner's activity can be seen
- What happens to guest data at exit
- Who is notified when the API version changes
What should you ask any vendor about their booking API?
Ask for the version policy, the permission model, the event signature and the exit, in writing, and ask which of them exist today rather than which are planned. A straight answer on status tells you more than any feature list.
| Question | A good answer sounds like | A warning sign |
|---|---|---|
| Version policy | "Two versions run at once; retirement is announced six months ahead" | "We keep it up to date" |
| Per-partner credential | "Each partner has its own credential and scope" | "We share one key with everyone" |
| Scope of actions | "Read availability and create bookings; cancellation is separate" | "The partner gets full access" |
| Revocation speed | "Withdrawn in minutes, by us or by you" | "We will look into it" |
| Event signature and secret rotation | "Every event is signed with a per-partner secret, rotated on request" | "The connection is secure" |
| Current status and connected partners | "This part is built; these partners are connected" | No distinction between built and planned |
Evidence beats description. Ask what happened the last time the API changed and what connected partners experienced. A vendor who cannot describe one real change has not run the process. Warning signs to watch for: the word secure with no mechanism behind it, no version number, one key shared by all partners, and no described way to withdraw access.
What to do next
The three adjectives describe three failures: a change that breaks a partner, a password that opens everything, a message nobody can verify. Make the next vendor you meet name the mechanism behind each word, and put the answers in writing. If you want to see how AI Otel has built these into its own partner door, request a briefing and we will walk through what is built and what is not.
Frequently asked questions
Is an API the same thing as an integration?
No. The API is the door and the rules for using it; an integration is the arrangement a particular partner builds on the other side. A hotel can have a well-built hotel booking API and no integration at all, which is exactly the case when a vendor says the API is built and no partner is connected.
Does OAuth mean my hotel's data is safe?
It means access is limited to named actions, attributable to one partner, and withdrawable without disturbing others. That is one control, not a safety certificate: it does not vet the partner, does not by itself encrypt data in transit, and does not replace a contract or a review of what the partner stores.
What happens to existing bookings if a partner's connection breaks?
Bookings already recorded stay in the hotel's system; what stops is the flow of new ones and of changes. That is why notice periods before a version retires, a named contact on both sides, and a way to notice silence matter more than the speed of the connection.
Can a hotel switch off a partner's access immediately?
With a per-partner credential it is a single act rather than a password change that breaks everyone. Ask the vendor to show how revocation works and how quickly it takes effect, and write the exit into the agreement before the first booking arrives.
Is AI Otel's partner API available to partners today?
It is built, and no partner is connected yet. The mechanism, including an AI assistant finding, holding and booking a room within limits the hotel sets, runs in a public demo environment on a fictional hotel. The demo shows how the door works, not a list of connected partners.