Do you own your data, or are you renting access to it?

Do you own your data, or are you renting access to it?

There's a simple question you can ask any system vendor, and the answer tells you more than the entire product brochure: What does it cost me to pull my own data in real time, and where's the documentation?

If the answer to the first part is a number, and the answer to the second is "contact sales," you generally already know enough.

This is written for the people who have to live with the integration afterward — IT leads, systems owners, developers in both hotel and event tech. Not for the people who sign the contract. We've seen enough five-year deals signed by a sales director who never opened the API docs to say this out loud: it's rarely the same people, and that's part of the problem.

Think of the API as a stance, not just a feature

The industry has gotten used to treating API access as a module you buy on the side. That's the wrong way to think about it. An API isn't something the vendor hands you on top of your own data — it is the access to your data, and that data is, as a rule, already yours. The bookings, the guests, the revenue, the functions on a conference. When a vendor charges you for programmatic access to information you entered yourself, that isn't really a pricing model. It's a lock-in strategy with a nicer invoice attached.

Let's be fair for a moment, because there is a legitimate version of this: high-volume metered usage genuinely costs something to serve, and it's reasonable for a vendor to charge you for running hundreds of thousands of calls a day against their infrastructure. That's not what we're talking about. We're talking about basic read access to your own data, placed behind an "enterprise" wall. The two things look identical on a price list. They aren't remotely the same thing when it comes to what they say about the vendor.

What a bad API looks like in practice

You recognize it when you meet it, but here's the checklist, since it rarely comes up in the sales meeting.

There's no OpenAPI specification. Instead you get a PDF, or a Confluence page last updated in 2021, or just an email address for an integration consultant who bills by the hour. Without a machine-readable spec, every integration becomes a reverse-engineering project, no matter how many times they tell you it's "simple."

There's no changelog, and breaking changes arrive without warning. You find out a field got renamed on the morning production stops. A vendor who doesn't version their API has effectively decided your uptime is your problem, not theirs.

The sandbox either doesn't exist, or behaves nothing like production. You build against the test environment, everything looks fine, and then you meet the actual data reality for the first time with real guests and real money on a Tuesday.

Authentication is a shared key in plain text, or basic auth over something that should have been retired long ago. Rate limits are undocumented, so you find them by hitting them — usually mid-release. And half the data you actually need isn't in the API at all. It's visible in the interface but not exposed, so someone on your team ends up scraping a screen in 2026, because that was faster than asking the vendor to expose the field.

On their own, each of these is just an annoyance. Together, they say something: the vendor hasn't prioritized making it easy for you to integrate.

Why this suddenly matters more than it used to

You may have lived fine with a mediocre API for years, because your integration needs were modest — a channel manager, an accounting system, maybe a lock system. What's changing the math now is AI.

Here's the part that's easy to miss: an AI agent is only as useful as the tools it's actually allowed to use. A language model that can't read your occupancy, create an offer, or check a room block is a chatbot guessing out loud. One that can do those things, through a clean API, is something else entirely. The precondition for all the AI vendors are now promising you is that systems can actually talk to each other programmatically. Without an API, it's just a demo, however convincing it looks.

And here's the term you've probably heard without quite pinning down: Model Context Protocol, MCP. It's an open standard for exposing your systems as tools an AI agent can call — structured, authenticated, with clear boundaries on what the agent is allowed to see and do. Think of it as a standardized contact point between the model and your business systems, instead of every vendor inventing their own version. The acronym itself isn't the important part. What matters is that MCP requires exactly what a bad API lacks: a well-defined, documented, secured interface to the data. Have that, and you're ready for agents. Don't have it, and you're buying an AI feature that's stuck behind the same wall as everything else in the system.

To be fair: doing this properly costs something

A vendor that offers a well-documented, versioned, open API is taking on a real cost. They have to maintain backward compatibility, keep the spec up to date, run a sandbox, manage a security surface that grows every time they expose something new, and answer support requests from developers who aren't their own employees. That's work, and it's entirely fair to charge for the value it creates — through the product price, through metered high-volume use, through support on integration projects.

The distinction isn't "free versus paid." It's whether the vendor is investing in you being able to move on, or investing in you staying put. The price of API access itself is almost a distraction here — look instead at whether there's a specification, a changelog, and a sandbox. That tells you which of the two vendors you're actually dealing with, regardless of what they charge for it.

What to demand?

Before you sign anything, ask to see four things with your own eyes — not just have them described in a meeting:

The full OpenAPI specification, before the contract is signed. A public changelog with a stated policy on breaking changes and how much notice you'll actually get. A sandbox you can build against the same day, without having to talk to a salesperson first. And a clear way out — what your data looks like the day you eventually want to leave, in a format you can actually use.

A vendor who shows you all four without hesitating has usually already decided that you own your data. That's the vendor worth building the next ten years on.