What your AI vendor means by “integration” – a translation guide for non-technical operators

Every proptech vendor pitch you sit through will include the word “integration,” and almost none of them mean the same thing by it. One vendor means they have a documented property management API with authentication, rate limits, and a changelog. Another means a nightly CSV drop onto an SFTP server. A third means a bot that logs into your PMS at 2 a.m. and clicks through screens like a very fast, very fragile temp worker. All three will say “we integrate with your system” in the same confident tone, and the difference between them is the difference between a project that ships in six weeks and one that quietly dies in month nine.

I’ve spent a long time running enterprise IT, and the single most expensive pattern I saw was a signed contract where both parties used the same word to describe two different things. This is a translation guide. It is written for operators who own the outcome but do not write code — the VP of Operations, the regional, the owner who has to explain to the asset manager why the rent roll still does not match.

The five things vendors mean when they say “integration”

When a salesperson says “we integrate,” ask them to describe the mechanism in one sentence with no adjectives. The answer will land in one of five buckets. Learn to sort them on the call.

1. A documented property management API

This is the real thing. A property management API is a published interface your vendor’s software calls directly to read or write data — units, residents, charges, work orders — using credentials you control. It has documentation you can read before you sign, versioning so changes do not surprise you, and error messages when something goes wrong.

The tell: ask for the documentation URL. A vendor with a real property management API integration will send you a link in under a minute, because their engineers use it daily. A vendor without one will offer a call with a solutions architect.

2. Flat-file exchange

The vendor drops or picks up files — usually CSV, sometimes a fixed-width format from 1997 — on a shared SFTP server, typically once a night. This is not a bad answer. It is durable, easy to audit, and has been quietly running the back office of the industry for decades.

It is also not real-time, and it is one-directional far more often than vendors admit. If the pitch was “our AI agent responds to residents instantly using live data,” and the mechanism is a nightly file, those two statements are in conflict and someone needs to say so out loud.

3. Screen scraping or RPA

A bot logs into your property management system with a real user account and drives the interface the way a person would. Vendors rarely volunteer this. You have to ask: “Does this run through a user login in our PMS?”

Screen scraping works right up until your PMS provider ships a UI change, moves a button, or adds a security prompt. Then it breaks silently, and you find out from a resident. It also means a vendor’s software is holding a credential with a real human’s permissions inside your system of record — worth a hard look from whoever owns your security policy.

4. “It’s on the roadmap”

Translation: it does not exist. This is legitimate if you are buying early and pricing accordingly, and indefensible if you are being sold a live capability. The distinction is whether the vendor will put a date and a remedy in the contract.

5. A person with a spreadsheet

Someone on the vendor’s team — or, more often, on yours — exports a report and uploads it somewhere. This is a legitimate starting point for a pilot. It stops being legitimate the moment it is described as an integration in a renewal conversation.

How the five compare

Who actually controls the property management API

Here is the part that surprises operators most, and it is the single biggest factor in proptech vendor selection: your AI vendor usually does not control whether the integration is possible. Your PMS provider does.

The major property management systems gate API access behind partner programs — approval processes, certification requirements, and in many cases per-property or per-transaction fees that land on your invoice, not the vendor’s. A vendor can have a beautifully built property management API integration and still be unable to turn it on for you, because they are not certified for your platform or your specific contract tier does not include the interface.

This is not a conspiracy; it is a business model, and it is worth understanding rather than resenting. But it means the honest question in any PMS integration conversation is not “do you integrate?” It is “are you an approved partner on our specific PMS, on our contract tier, and who pays the interface fee?”

It is also why there is no easy standards answer here. Residential brokerage largely converged on a common data standard through the RESO Web API, which gives that side of the industry a shared vocabulary for property data. Multifamily operations never reached the same level of adoption, so every property management API you encounter is effectively its own dialect. Plan for translation work, not plug-and-play.

The five questions that end the ambiguity

Ask these on the second call, before the proposal. You do not need to understand the answers technically. You need to hear whether they are specific.

• “Walk me through the mechanism in one sentence.” API, file, bot, human, or nothing. Everything else follows from this.
• “Which direction does data move, and which system wins a conflict?” If a resident’s phone number differs in two systems, one has to be authoritative. Vendors who have shipped real integrations answer this instantly.
• “How often does it sync, and what happens between syncs?” This converts “real-time” from a marketing word into a number.
• “Name three customers on our exact PMS and version.” Not three customers. Three on your platform. “Version” catches the vendor who integrated with a product generation you are not on.
• “What breaks it, and how would we find out?” A vendor who has run production integrations has a list. A vendor who has not will say “nothing, really.”

What “real-time” actually means

Nobody lies about this so much as they round. In practice, “real-time” in a property management API context means anything from sub-second webhook delivery to a fifteen-minute polling loop to a nightly job that someone once described as real-time in a deck and never corrected.

The operational question is not the number itself. It is whether the number is compatible with the promise. An AI leasing agent quoting availability from data that is up to 24 hours old will confidently offer a unit that was leased yesterday. That is not a technology failure — it is a mismatch between a stated capability and its actual mechanism, and it is entirely findable before you sign.

The security questions nobody asks until it is too late

Any integration mechanism means a third party holds access to resident data. Three questions cover most of the exposure, and none of them require a security background to ask.

First, what credential does the vendor hold — a scoped API key you can revoke independently, or a named user login inside your PMS? Second, what data leaves your system, and is it limited to what the use case actually needs? Third, when the contract ends, what is the deletion process and how is it confirmed in writing?

If you want a reference point for what good looks like, the OWASP API Security Project maintains a widely used list of the most common API failure modes. You do not need to read it cover to cover. Sending it to a vendor and asking which items they have controls for is a fast, low-drama way to see whether they have a security practice or a security paragraph.

What to put in the contract

Three clauses do most of the protective work in PMS integration deals, and none of them are exotic.

Name the mechanism explicitly — “REST API,” “SFTP file transfer,” “browser automation” — so “integration” cannot be reinterpreted later. Tie a payment milestone to the integration passing acceptance in your environment, not to signature or to a demo on the vendor’s data. And define what happens if your PMS provider changes or revokes the interface: who fixes it, on what timeline, and whether you can exit without penalty if it stays broken.

None of this requires a technical negotiator. It requires refusing to let a word stay undefined in a document you are signing.

Do this before your next vendor call

Pull up the last proptech contract you signed and find the word “integration.” Then find the sentence that defines the mechanism. If there isn’t one — and there usually isn’t — email the vendor and ask which of the five buckets above describes what is running in your portfolio today, and whether the property management API access it depends on is licensed to you or to them.

You will get one of two responses. A specific answer with a documentation link, which tells you that integration is solid and you can stop worrying about it. Or a scheduling request, which tells you exactly where to spend your attention next quarter. Either result is worth the ten minutes.