An open API on your property management system is not permission to connect an AI tool to it. It's a diligence event, and most operators are about to skip the diligence.
The news is moving fast. Tenant Inc. opened its Nectar API to AI tools on 13 July, so you can point Claude, ChatGPT or any AI agent straight at live Hummingbird data with no developer and no wait for a roadmap item. It isn't the only one. QuikStor has added three integrations in as many months. The vendors call this openness. For a growing multi-site operator, it's a new decision that needs to be made on purpose.
The excuse is gone
For years, "our systems don't talk to each other" was a vendor problem. The PMS was a walled garden, and getting anything out of it took a developer or an integrator. That excuse is disappearing.
So the next mistake won't be "we couldn't connect our data." It'll be "we connected it before we knew what it said."
A mapping error at machine speed
Picture a 22-site operator, half the portfolio acquired over six years. Every acquisition arrived with its own unit-type naming, its own discount codes and its own idea of what "occupied" means during a lock-out dispute. Nobody has reconciled that across the portfolio, because nobody has ever needed to read all 22 sites side by side in real time.
Now someone in operations points an AI reporting tool at the open API. It takes an afternoon, not a developer sprint. In the first week it produces a clean occupancy trend chart, and somebody acts on it. Then it turns out three of those sites code "occupied" differently. The trend is a mapping error, not a fact about the business.
The AI tool didn't lie. It read exactly what it was given, faster and with more confidence than a person would, and nobody had checked whether the data underneath was safe to trust at that speed.
That's the real risk, and it has nothing to do with the AI. An open API doesn't create clean data. It creates a much faster path from whatever data you have to a decision someone will act on.
If your systems already reconcile - one taxonomy, one source of truth per metric, a named owner for each integration - an open API is a real gift. You skip paying an integrator for the basic plumbing and build straight on top. If they don't reconcile yet, the open API just gives the gap a shorter fuse.
The scope question nobody asks
The second layer is access scope. "Open API" tells you the door exists. It doesn't tell you what the tool on the other side can do. Read-only on reporting fields? Or can it also touch billing, access control and lease terms?
Vendors publish developer docs. They don't publish a risk assessment for your stack. That's a decision the operator has to make deliberately, not one that gets made by default because the connection worked first time.
Two days now or two days later
I don't recommend treating "the API is open" as the trigger to connect. The trigger should be a written answer to which fields reconcile across every site, who owns each integration once it's live, and what access you're granting.
For a mid-sized operator who has never mapped it, that's roughly two days of work. Skipping it doesn't save the two days. It moves them to after something has already gone wrong in front of ownership.
Openness is the right direction
None of this is an argument against open APIs. The direction is right, and operators who have done the mapping should move faster than they are. Nectar and whatever follows it are useful once the plumbing underneath is sound.
The argument is against treating vendor openness as a substitute for your own architecture work. The vendor's incentive is to look integration-friendly. Whether your data is fit to hand to an AI tool at that speed is a question only you can answer, and it's worth answering before the connection, not after the first bad report is presented as fact.
Checking what sits behind the door before anyone walks through it is what our architecture review is for.
← Back to the blog
