Then we say so before you pay, not after. Sometimes exports are enough; sometimes they are not.
Published September 7, 2026
It happens more than vendors admit, particularly with older property management software and with systems where API access sits behind an enterprise tier you are not on.
Our position is straightforward: if we cannot reach it, we say so before you pay rather than after. An optimistic answer here does not help anyone, because the problem surfaces during launch week when expectations are already set.
It is worth being precise, because it is not everything. The thing that genuinely requires live access is anything that changes minute to minute.
What it does not rule out is a large amount of useful work: answering policy questions, qualifying inquiries, booking into a calendar, running follow-up, triaging maintenance and taking payment.
A scheduled export is the common one. If your system can produce a file of units, rates and availability a few times a day, the agent can answer from that. It is a compromise, and the honest framing is that availability answers carry a freshness caveat rather than being live.
Structured email into an intake address your system already monitors covers a lot of the write side. Some systems also expose more than their marketing suggests, so it is worth asking your vendor directly rather than assuming.
Sometimes, but that is a separate decision with its own business case, and it should not be smuggled in as part of an automation project.
If your software is already limiting you in other ways, this may be one more reason on an existing list. If it works well and simply lacks an API, replacing it to enable automation is usually the tail wagging the dog. Start with what can be done without a migration, and revisit if the constraint turns out to bite.
Ask your PMS vendor three things: whether an API exists, whether your plan includes it, and whether it covers reading availability and writing work orders. Most support teams answer that in a day, and it changes the shape of the conversation before anybody commits to anything.
One approach that comes up when there is no API is automating the interface itself: a script that logs in the way a person would and reads the screen.
It is technically possible and we treat it as a last resort. It breaks whenever the vendor changes a layout, it often sits awkwardly against the terms of service, and it tends to need credentials with broader access than the job requires. If somebody offers it as the solution to your missing API, ask what happens the week your vendor ships a redesign.
The honest test is to look at which questions your callers actually ask, in what proportion, rather than at the list of things that would theoretically be limited.
That framing turns a technical constraint into a business judgement, which is where it belongs. Nobody should be deciding this on the basis of whether a connection is possible in principle.
On the site
Keep reading