Short answer: a property-management integration playbook should define the system of record, expected data flow, identifiers, schedule, freshness target, duplicate rule, failure alert, retry behavior, reconciliation test, exception owner, stop control, credential owner, recovery evidence, and retirement path for every connection. A successful API response is not proof that the business record is complete or correct.
AppFolio describes an integration marketplace intended to connect property-management workflows with partner services. Buildium describes an Open API and marketplace integrations that extend portfolio data and workflows. Those capabilities make ownership and reconciliation more important, not less. This independent playbook is vendor-neutral and does not certify a connector, guarantee delivery, or replace security, accounting, privacy, contractual, or technical review.
Inventory every connection and business purpose
List APIs, webhooks, scheduled imports, exports, bank feeds, payment connections, listing feeds, screening services, email, calendars, storage, analytics, maintenance partners, and automation identities. Name the business workflow and owner. A connection with no current purpose, owner, or review date should be investigated and retired when appropriate.
Declare the system of record by field
One application may own property identity while another owns payment settlement or signed documents. Define authority for each important field, permitted direction, transformation, and conflict rule. Avoid describing an entire platform as authoritative when several domains have different owners.
Map identifiers and expected volume
Record organization, property, unit, resident, lease, vendor, transaction, work-order, document, and external identifiers. Define expected cadence and approximate volume. Missing or duplicate events are difficult to detect when the team does not know whether a normal period contains ten records or ten thousand.
Monitor business outcomes as well as transport
Track authentication failures, timeouts, rejected payloads, schema errors, delayed webhooks, retry backlog, duplicates, and rate limits. Also test whether charges, payments, listings, documents, work orders, or messages reached the correct record and status. Use the data quality scorecard to weight defects by operational consequence.
Reconcile control totals and samples
Compare source count, destination count, accepted count, rejected count, duplicate count, total amount where relevant, earliest and latest timestamps, and a sample of record-level fields. Reconciliation must define period, filters, timezone, status, currency, and exclusions so both sides measure the same population.
Download the integration playbook
Download the editable integration failure and reconciliation playbook (CSV). It covers ownership, data flow, identifiers, monitoring, expected totals, exceptions, retries, stop controls, credentials, recovery, validation, and retirement.
Make retries idempotent and controlled
A retry should not create a second charge, resident, work order, message, or document. Record idempotency key or duplicate rule, maximum attempts, delay, dead-letter or exception path, manual approval threshold, and replay evidence. Do not bulk replay an unknown backlog directly into production.
Contain failures without losing evidence
Pause the affected workflow where continued execution increases harm. Preserve payload references, timestamps, correlation identifiers, logs, configuration version, and affected record list without copying secrets or unnecessary personal data into an incident note. Connect consequential failures to the automation approval and exception register.
Protect and rotate connection credentials
Document credential type, owner, scope, storage method, expiration, rotation, last use, and revocation test. Apply the least access needed and include integration identities in the software permissions matrix. Never place live secrets in a downloadable template.
Validate recovery and prevent recurrence
After repair, reconcile the complete affected period, confirm downstream workflows, notify responsible teams, document residual exceptions, and test monitoring. Root causes may include data quality, changed schemas, expired credentials, rate limits, unsupported configuration, network failure, permission drift, or unclear system ownership.
Frequently asked questions
How often should integrations be reconciled?
Set cadence from consequence and volume. Financial or resident-facing flows may need daily or near-real-time controls, while lower-risk reference data may suit a less frequent review. Document the rationale and maximum acceptable delay.
Is a vendor status page enough monitoring?
No. It may describe service availability, but it cannot prove that your records were complete, correctly mapped, and applied to the intended property workflow.