An 85-room San Francisco hotel built its own AI rate tool on the Cloudbeds API

Union Square Plaza Hotel, an independent 85-room property in San Francisco's theatre district, has built custom inventory and rate tools against Cloudbeds' API rather than waiting for an integration to appear in the marketplace. The owner, Sal Patel, says he is not a software engineer. He used AI tools to write the integrations.

The furthest along is AI-assisted rate management, which pulls availability, occupancy, current rates and reservations together to inform pricing decisions. The longer-term goal Patel describes is a conversational layer where staff ask a plain English question about a date, occupancy or pricing and get a recommendation with the reasoning attached. He is clear that the hotel still makes the call. Inventory, reservations, revenue strategy and distribution analysis are listed as areas still being explored.

Two things make this worth more than the usual customer story.

The access question

Cloudbeds' claim, repeated in the case study, is that every endpoint is available through its open API with no premium tier and no separate developer agreement. That is Cloudbeds' own statement and it has not been independently verified, but if it holds it is unusual.

A PMS API index published last month scored 343 vendors on API access and found only 7% publishing open documentation. Charging for API access, gating it behind a partner programme, or rationing endpoints by plan tier is closer to the industry norm than the exception. For an 85-room independent, those gates are usually the end of the conversation, because the cost of the integration tier exceeds whatever the tool was going to save.

Patel's point is really about dependency. He says he did not want the hotel's ability to try things to rest on whether a particular third-party integration existed. That is a different argument from the usual one about saving money on software, and it is becoming more common now that writing a working integration no longer requires hiring a developer.

What the story does not contain

There are no results. No revenue figure, no time saved, no occupancy or ADR movement, no adoption numbers. The case study is vendor-contributed content and it does not claim a measurable outcome, which at least makes it honest about its stage.

Patel also notes a learning curve and puts weight on the quality of API documentation. Both are worth taking seriously. Tools written this way are not maintained by anybody but the person who wrote them, and an API change, a staff departure or an owner's attention moving elsewhere leaves a hotel running on something nobody understands. That risk is real and the case study does not address it.

For operators weighing this up

The transferable lesson is not that you should build your own revenue tool. It is that API access is now a specification to check when you choose a PMS, in the same way you check channel manager coverage or payment processing.

Three questions are worth asking any vendor on a shortlist. Which endpoints are available on the plan you will actually buy, not the enterprise tier. Is the documentation public, so you can look at it before signing. And is there a separate developer agreement or per-call charge waiting behind the integration.

Most properties will never write a line of code against the answers. But the answers determine which tools you can bolt on later, and that is a decision you make once, at purchase, and live with for years.