Report which Buildium environment this server is bound to (sandbox, production read-only, production read-only with file downloads, or production with writes), the active write mode, how many operations are indexed, where downloads go, and — if the server is not configured — exactly what to set.

Only needed before a WRITE, when the environment is genuinely in doubt, or when another tool reports a startup problem. Read-only questions do not require it.

List every resource area in the Buildium API with its operation count (Leases, Work Orders, General Ledger, ...). Use this to orient before searching.

Find Buildium API endpoints by keyword.

Searches paths, summaries, tags, and operation IDs across all 462 operations. Start here when you don't already know the exact path.

Show the full contract for one endpoint: parameters, request body schema, and success response schema, with $refs resolved.

Call this before buildium_call_endpoint on anything non-trivial — especially writes, where the body schema tells you which fields are required.

Expand a named schema from the spec. Useful when buildium_describe_endpoint hit its depth limit and emitted a bare $ref.

Read any Buildium endpoint (GET). Cannot change anything.

Use this for every read that has no curated shortcut. It is a separate tool from buildium_call_endpoint so that a client can approve reads once and still ask about each write.

Call any Buildium endpoint: the tool for writes.

For reads use buildium_get, which is read-only and so can be approved once.

Write guardrails apply — see buildium_health for the active mode. In the default 'fixtures' mode, every name in a create payload must carry the fixture prefix, nested ones included; a create whose payload has no name field at all is allowed against the sandbox but refused against production, since nothing on it could carry the prefix. Updates and deletes only work on records created this session, and off the sandbox so do creates under an existing record, such as a lease renewal.

List records created during this session, grouped by collection. These are the only records that updates and deletes are permitted against in 'fixtures' mode. Also appended to created-records.log (see buildium_health for the path) so they can be cleaned up after the process is gone.

Upload a local file to Buildium, handling both steps of its upload flow.

Bytes do not travel through the Buildium API. Buildium issues a short-lived AWS presigned PUT URL, and the file is sent there directly. Doing that by hand with buildium_call_endpoint does not work — it would post the metadata and hand you a URL it cannot then PUT to. Use this instead.

Download a Buildium file to this machine, handling both steps.

Buildium issues a download URL that expires after five minutes and serves the bytes from separate storage, so this cannot be done with buildium_get.

Files are written only inside the download folder — ~/Downloads/Buildium unless BUILDIUM_DOWNLOAD_DIR moves it; buildium_health reports where. An existing file is never replaced unless overwrite is true.

Note this is refused when the server runs in production-readonly mode: Buildium models a download request as a POST, and that mode blocks every POST at the transport layer without exception. Reading file metadata via GET /v1/files/{id} still works.

List rental properties. Pass fields to narrow large records.

To count, use count_only; for totals, all_pages.

Get one rental property by ID.

List rental units, optionally filtered to one property.

To count, use count_only; for totals, all_pages.

List leases.

Each row already carries the rent terms under AccountDetails (including AccountDetails.Rent, the recurring monthly amount) and the lease dates. You do NOT need to open the transaction ledger to read a lease's rent — buildium_list_lease_transactions is for actual posted charges and payments, which is a different question.

For who is on each lease, use buildium_lease_roster.

To count, use count_only; for totals, all_pages.

Get one lease by ID, including tenants and rent terms.

List financial transactions (posted charges and payments) for a lease.

For the lease's recurring rent amount use buildium_list_leases instead — it is already on every row under AccountDetails.Rent.

Set all_pages=true when totalling a ledger, and count_only=true to learn only how many transactions there are.

List work orders (maintenance jobs).

To count, use count_only; for totals, all_pages.

List rental tenants.

To count, use count_only; for totals, all_pages.

Who is on which lease — the lease-to-tenant join, done in one call.

Use this for any "who lives in / who is on lease X" question, and for counting co-tenants.

Buildium makes this awkward: the lease list does not reliably populate tenant names, and the tenant endpoint has no lease filter — so answering it directly means pulling every lease one at a time. Tenant records do carry their lease membership, so this reads them and inverts the mapping locally.

Every matching tenant is read, following pagination; complete says whether that covered them all. Above 300 leases only the counts are returned (multi_tenant_lease_count and friends); narrow with property_id or lease_id for lease ids and names.

List general ledger accounts. You need these IDs to post rent charges and other financial transactions.

To count, use count_only; for totals, all_pages.