Buildium API: What Syncs?

The Buildium API integration connects your Buildium account directly to Aptly so your property, unit, lease, tenant, owner, vendor, and work order data stays in sync between both systems. Instead of duplicating data entry, you manage your day-to-day workflows in Aptly — leasing, renewals, maintenance dispatch, owner communication — while Buildium remains your accounting and source-of-record system for financials.

This article explains exactly which fields sync, in which direction, and which fields are read-only in Aptly. Use it as your reference when designing boards, building automations, or troubleshooting why a field isn't updating the way you expect.

Knowing the sync direction of each field up front saves hours of "why isn't this updating?" debugging later.

Every field in the Buildium integration falls into one of three categories:

The Buildium sync populates the following core boards in Aptly:

Each board has its own card type with fields that map to Buildium entities. When data changes in Buildium, the corresponding card in Aptly updates automatically — typically within a few minutes.

Buildium maintains relationships between entities (a unit belongs to a property, a lease belongs to a unit, a work order is tied to a property or unit). Aptly preserves these as location links and unit links on the relevant cards. These links are read-only because they reflect Buildium's record structure — if you need to move a lease to a different unit, you do that in Buildium and Aptly will follow.

What this means in practice: You can update basic property info — address corrections, structure descriptions, reserves — from inside Aptly and it'll push to Buildium. But the Rental Type, active status, and insurance details are managed exclusively in Buildium, so don't build workflows that try to edit those fields from Aptly.

What this means in practice: Marketing teams can manage listing status, market rent, and marketing descriptions from Aptly — useful when your leasing board automations need to flip a unit to "Published" upon vacancy. Occupancy status is read-only because Buildium derives it from active leases, so to mark a unit occupied you have to create the lease in Buildium (not toggle a field).

What this means in practice: This is the board where understanding sync direction matters most.

What this means in practice: The Owner contacts are read-only and attached to the Building. Owner records must be created and edited in Buildium. Aptly pulls owner data for use in your owner communications, reporting boards, and automations, but any owner updates need to happen in Buildium first.

What this means in practice: Vendors are one of the most flexible entities in the integration. You can fully onboard a new vendor from Aptly — name, contact info, tax setup, category — and it'll create the record in Buildium. GL account assignment and vendor insurance remain Buildium-managed because they're tied to accounting and compliance workflows.

What this means in practice: Work orders are designed for two-way sync because maintenance is typically the most operational workflow in Aptly. You can create a work order in Aptly — assign vendor, set priority, link the unit — and it'll appear in Buildium. The Amount field is read-only because it's pulled from the linked bill/invoice in Buildium's accounting side.

Go to Settings → Integrations → Buildium and follow the connection flow. You'll need your Buildium API credentials (your Buildium admin can generate these from Buildium → Settings → API Keys).

After connecting, navigate to your Properties, Units, Leases, and Vendors boards. You should see your Buildium records populating as cards within a few minutes for a small portfolio, longer for portfolios over 1,000 units.

Before building any boards or automations, look at the tables above and circle which fields your team needs to edit from Aptly vs. which they just need to see. This decision drives how you build the rest of your workflows.

If you want a field from one Buildium-synced board to appear on a different board (for example, showing Market Rent from the Units board on a Leasing pipeline board), use a mirror field that pulls from the synced source field. Mirror fields inherit the sync direction of the source — so a mirror of a read-only field is also read-only.

If a field is read-only in the sync, it's read-only for everyone in Aptly. If you The fix is always: update it in Buildium and let it flow back.

Updates typically propagate within a few minutes, but during high-volume periods (end of month, mass lease renewals) it can take longer. If you're testing a workflow and don't see a change immediately, give it a few minutes before assuming something is broken.

Aptly is conservative about deletions. Archiving or removing a card in Aptly will not delete the underlying record in Buildium. If you need to delete a property, lease, or vendor permanently, do it in Buildium.

Only the fields listed in the tables above sync between systems. Custom fields you've created in Buildium will not appear in Aptly. If you need additional data points, create them as custom fields directly in Aptly — they'll live alongside the synced fields.

This is intentional. You can collect a tenant's DOB through Aptly Screening and push it to Buildium, but changes made in Buildium afterward won't pull back. If your tenant intake process lives in Aptly, treat Aptly as the source of truth for this one field.

Anything tied to money — security deposits, delinquency, GL accounts, owner tax info — should be managed in Buildium. These are deliberately read-only in Aptly to prevent accidental edits that could create accounting discrepancies.

Workflows that involve coordination, communication, and tasks — leasing, renewals, maintenance dispatch, vendor onboarding — belong in Aptly. The read/write fields are specifically the ones property managers touch most often in those workflows.

Since Lease To Date is read/write, you can build a full renewal workflow in Aptly: surface leases expiring in the next 90 days, run your renewal offer process, then update the end date from Aptly — and it'll flow back to Buildium when the renewal is signed.

A common pattern: build a Collections board where cards automatically move lanes based on which delinquency bucket they fall into (0-30, 31-60, 61-90, 90+). The buckets are read-only, but they're powerful as triggers for assigning tasks, sending notices via Aptly's email tool, or escalating to legal.

Because nearly every vendor field is read/write, you can build a clean vendor intake workflow in Aptly — collect W-9 info, set the 1099 toggle, categorize them — and the vendor will appear fully formed in Buildium. This is much faster than going back and forth between systems.

It's tempting to mirror every Buildium-synced field onto every board, but mirror fields add visual clutter and can slow board performance. Only mirror what you'll actually use for filtering, automations, or display.

Check the sync direction in the table above. If the field is read only, edits made in Aptly won't persist — the next sync will overwrite them with Buildium's value. The fix is to make the change in Buildium instead.

First, give it 24 hours. If it still isn't appearing, check:

Most likely you're trying to set a read-only field. Open the automation, check which field it's writing to, and cross-reference the table above. If it's read-only, the automation needs to be redesigned — either to write to a different (Aptly-only) field, or to trigger a notification telling someone to make the change in Buildium.

Delinquency is calculated by Buildium based on the latest accounting transactions. If a payment was just posted, the balance update may not have processed in Buildium yet. Verify the balance in Buildium first — if it's correct there, give Aptly a few hours to pull the update.

Tenant contact fields are read/write, which means they can be edited in either system. If they're out of sync, someone may have edited one side during a brief sync delay. The most recent edit should win on the next sync cycle. If the discrepancy persists, update in Buildium directly and the value will flow back to Aptly.

This is expected behavior. Aptly does not propagate deletions to Buildium. To fully remove a record, delete it in Buildium — and the Aptly card will follow.

If you run into a sync issue not covered here, reach out to your dedicated Aptly account team with the board name, card name/link, and field name involved, and we'll investigate from the integration logs.