Reference · built on requestConnectorHospitality & property systems

Buildium

Rental properties, leases, tenants, work orders, bills, and general ledger data from Buildium accounts.

Request accessPricing ↗

About

Buildium is property management software for residential rentals and community associations. Its Open API at api.buildium.com/v1 covers rental properties and units, owners, tenants, leases and lease transactions, associations, resident and to-do requests, work orders, vendors, bills, bank accounts, and the general ledger, with webhook events named entity.operation, such as Rental.Updated.

Through Fibric, an operator watches requests, work orders, and lease balances and proposes a work order, a charge, or a note for your approval. Each approved change is written once and leaves a receipt: what changed, why, and how to undo it.

This is a reference listing. It documents what Fibric would read from Buildium and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Rental properties and units through GET /v1/rentals and /v1/rentals/units, with their owners and tenants
  • Leases, move outs, renewals, and rent schedules through /v1/leases, plus lease transactions, charges, and outstanding balances
  • Resident requests, to-do requests, and work orders through /v1/workorders, with WorkOrder.Created and WorkOrder.Updated events
  • Tasks and task history through /v1/tasks, with Task.Created, Task.Updated, and Task.Deleted events
  • Bills, bill payments, vendors, and bank account transactions through the Accounting endpoints
  • General ledger accounts, balances, and transactions, and the accounting lock periods
  • Associations, association units, owners, and ownership account transactions

Proposed actions

  • Target capability: propose a work order through POST /v1/workorders, or an update through PUT
  • Target capability: propose a lease charge or a payment through the lease transactions endpoints
  • Target capability: propose a resident request or to-do request update
  • Target capability: propose a note on a lease, tenant, property, or vendor
  • Target capability: propose a bill through the Bills endpoints

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Route each resident request

    Resident requests and to-do requests arrive with the property and unit. The operator proposes the work order and vendor and records who approved it.

    With Request Routing

  • Chase aging work orders

    WorkOrder.Updated events and GET /v1/workorders show what is still open. The operator proposes the vendor follow-up or the escalation and leaves a record.

    With Work Order Aging, Vendor SLA Watch

  • Notice delinquency early

    Lease transactions and outstanding balances show who is behind. The operator drafts the delinquency notice and holds it for your approval.

    With Delinquency Notice

  • Prepare lease expiries

    Upcoming renewals and lease end dates set the queue. The operator proposes the renewal offer or the move-out plan per unit.

    With Lease Expiry, Unit Turn

Requirements

  • A Buildium account on the Premium subscription, which is required for the Open API
  • An administrator user who turns on the Open API toggle under Settings, Application settings, Api settings
  • An API key created under Settings, Developer Tools, with the data areas it may access ticked; the secret is shown once
  • For events, a webhook added under Settings, Developer Tools, Webhooks pointing at a public https endpoint
Authentication
An account-level API key: a client ID and secret sent on every request as the x-buildium-client-id and x-buildium-client-secret headers; missing or wrong values return 401.

Limits

  • 10 concurrent requests per second per client; over the limit returns 429, and Buildium suggests a retry after about 200 ms
  • Query strings are capped at 4096 characters and return 500 when longer
  • Webhooks wait 10 seconds for a 2XX, retry after 1 minute, 10 minutes, and 1 hour, then stop
  • One sandbox per Premium account, capped at 1500 units, sending no emails; production keys do not work there

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Buildium ↗

Questions and answers

Which Buildium plan includes the Open API?
The Premium subscription. An administrator turns on the Open API under Settings, Application settings, Api settings, then creates API keys under Settings, Developer Tools, choosing which data each key may reach. The Premium plan also allows one sandbox account at apisandbox.buildium.com.
How do Buildium webhooks work?
You add a webhook under Settings, Developer Tools, Webhooks with a public https endpoint. Buildium posts an Event object with EventName such as Rental.Updated or WorkOrder.Created, EventDateTime in UTC, AccountId, and the entity ids; you fetch the full record through the API.
What rate limit does Buildium enforce?
10 concurrent requests per second per client, on the production and sandbox hosts alike. Exceeding it returns 429; retry after about 200 ms. List endpoints page with limit and offset, defaulting to 50 results, and query strings over 4096 characters return 500.
Ask about Buildium

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Buildium through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy