An integration badge is not a control

Treat an integration badge as a starting point, not evidence that your records are protected. Before relying on a PMS connection, define the business job, inspect permissions and field mappings, trace one record, test duplicates and outages, assign exception ownership, reconcile the result, and prove that access and data can be removed cleanly.

In this article

A marketplace listing answers whether a connection is available. For a small landlord, the consequential questions begin afterward: Which properties can it see? Which records can it change? Which system wins when values conflict? What evidence appears after a failed write? What remains connected after cancellation?

Official vendor material illustrates the gap. Buildium’s Open API documents webhook retries, possible duplicates, out-of-order delivery, signatures, and sandbox testing. QuickBooks tells integrators to acknowledge webhooks quickly, process asynchronously, and use Change Data Capture to recover missed changes. Stripe documents idempotent requests and duplicate webhook handling. Those are not obscure engineering footnotes. They describe conditions that can change a tenant ledger or vendor payment.

Picture an owner connecting a leasing add-on to a PMS. The setup takes minutes, and the first applicant appears correctly. A month later, a unit is renamed, an older event arrives late, and the add-on creates a second unit record. The portfolio is small enough that the owner notices—but only after a document and two messages attach to different versions of the same apartment.

The useful artifact is not another dashboard. It is a one-page integration register linked to the field map and event history: purpose, scopes, system of record, source and destination IDs, write effects, owner, failure route, and removal steps. That packet turns “the apps got confused” into a repairable sequence.

A polished demo usually shows one valid record moving once over a healthy connection. Reverse the conditions. Send the event twice. Deliver an older update after a newer one. Remove a required field. Revoke the credential. Let the destination time out after accepting a write. Then look for one correct final state and a complete record of every attempt.

The worst result is not always an error screen. It is quiet plausibility: one ledger that missed a payment, two work orders that both look legitimate, or an AI reply grounded in yesterday’s balance. Visible, bounded failure is safer than silent success because the owner knows where judgment is required.

When comparing software, ask vendors to demonstrate delivery history, duplicate handling, provider receipts, field-level mapping, reconciliation, and offboarding. Grant read-only access before write authority when possible. Keep money movement, applicant decisions, and legally sensitive communication behind a human gate until the recovery evidence is repeatable.

This is not a demand for zero failure. Networks fail, schemas change, credentials expire, and people correct records. The standard is whether the product preserves custody of the work: one named exception, its source evidence, the safe next action, and a way to confirm the destination after repair.

The owner should be able to export records in usable form, identify open jobs, revoke tokens, remove webhooks, stop scheduled syncs, and confirm what the provider retains. Cancelling a subscription charge is not evidence that access ended. The integration register gives each removal step an owner and receipt.

Run that exit review before the relationship becomes urgent. A product that cannot explain its identifiers, mapping, and export while the account is healthy will be harder to leave after an incident or price change. Portability is not only a migration feature; it is leverage to correct a bad technology decision without abandoning the property history.

Key takeaways

Ask what data and properties it can access, what it can change, which system is authoritative, how it handles duplicates and missed events, where errors appear, how results reconcile, and how tokens, webhooks, jobs, and retained data are removed.

Yes. A sandbox or isolated test account lets an owner exercise duplicates, mapping errors, retries, and reversals without altering live tenant, lease, or accounting records.

Keep the invented input, source and destination IDs, mapping version, event and retry history, provider receipt, expected result, actual result, exception owner, correction, and retest outcome. That packet makes the decision reproducible after staff or software changes.