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, 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.

Deliberately not wrapped by _guarded: this is the one tool that must answer when everything else cannot, so it reports status rather than raising.

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.

query: natural keywords, e.g. "work orders", "lease transactions", "gl accounts" method: optionally restrict to get/post/put/patch/delete

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 (e.g. "LeasePostMessage"). Useful when buildium_describe_endpoint hit its depth limit and emitted a bare $ref.

Call any Buildium endpoint.

method: GET, POST, PUT, PATCH, or DELETE path: e.g. "/v1/leases" or "/v1/leases/12345" query: query-string parameters body: JSON request body for writes fields: keep only these top-level fields in the response. Buildium records are large — passing e.g. ["Id","Name","PropertyIds"] avoids pulling tax IDs and full addresses you did not ask for. confirm: required (true) for DELETE all_pages: GET only — follow pagination to the end instead of returning the first page. Use it whenever you are counting or aggregating; a count taken from one page is wrong whenever the collection is larger than the page.

Write guardrails apply — see buildium_health for the active mode. In the default 'fixtures' mode, created records must carry the fixture prefix in their name, and updates/deletes only work on records created this session.

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 — call_endpoint would post the metadata and hand you a URL it cannot then PUT to. Use this instead.

file_path: path to the file on this machine title: the file's title in Buildium. In 'fixtures' write mode this must start with the fixture prefix (see buildium_health). category_id: from GET /v1/files/categories — required, and Buildium rejects the upload without a real one. entity_type: what the file is attached to — Rental, Lease, Tenant, Vendor, Association, RentalOwner, RentalUnit, and so on. entity_id: the ID of that record. upload_path: for files belonging to a bill, check, or task history, pass that resource's own uploads path, e.g. "/v1/bills/123/files/uploads". Only Buildium's seven upload-request endpoints are accepted here, in every mode.

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_call_endpoint.

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.

file_id: from GET /v1/files save_to: where to write the file on this machine download_path: for a file belonging to a bill, check, or task history, that resource's own download path, e.g. "/v1/bills/123/files/456/downloadrequest". Only Buildium's seven download-request endpoints are accepted here, in every mode.

List rental properties. Pass fields to narrow large records.

Set all_pages=true to follow pagination to the end in one call — do that whenever you are counting or aggregating, since a single page is only the first 50 records and a count taken from it will be wrong.

Get one rental property by ID.

List rental units, optionally filtered to one property.

Set all_pages=true when counting or aggregating; one page is not the whole collection.

List leases. lease_status is one of Active, Future, Past, Expired.

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.

Set all_pages=true when counting or aggregating across every lease.

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.

List work orders (maintenance jobs).

Set all_pages=true when counting or aggregating.

List rental tenants.

Set all_pages=true when counting or aggregating.

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 fetches them once and inverts the mapping locally.

lease_id: restrict to a single lease property_id: restrict to leases at one property exclude_fixtures: drop tenants created by test tooling (names starting with the fixture prefix — see buildium_health). This sandbox accumulates such records permanently, because Buildium offers DELETE on only 14 of its 462 operations. When any are present the response says so, so a count is never silently wrong.

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

Set all_pages=true when counting or aggregating.