API Report Card · PM Software · Methodology v1.1
Buildium
Where the points came from.
Five categories, each worth a fixed share of the 100 points. A category earns the fraction of its checks it passes, times its maximum.
Functional Coverage
Design & Reliability
Access Control
Docs & AI-Ready
Access & Cost
Letter grades are absolute, never curved.
The same numeric bands apply to every platform. Nothing here is scored relative to the rest of the board.
What this means for you.
One paragraph per category, in plain language.
1 · Functional Coverage
Reads and writes nearly everything the business runs on: properties, units, leases, tenants, ledgers, bank accounts, bills, tasks, and work orders. Nothing critical is missing, and 91 webhook event types push changes to you in near real time.
2 · Design & Reliability
Modern, well typed, paginated, versioned, and openly monitored. Four gaps need code on your side: error responses carry no stable machine code, there are no idempotency keys (so a retried payment can double post), there is no lock stopping two writes from overwriting each other, and the only per-request trace id is an AWS header rather than a Buildium one.
3 · Access Control
A perfect score. Issue a read-only key for a reporting agent, scope a key to just the data an app needs, make one key per integration, and rotate or delete any of them yourself. A real sandbox exists and its keys cannot touch production.
4 · Docs & AI-Ready
A developer or an AI tool can build against Buildium without reverse-engineering it. The reference is public and complete, the OpenAPI file drives code generation, and the changelog was current to nine days before the run. The gap is AI-native docs: no llms.txt, so an agent has to consume the OpenAPI file itself.
5 · Access & Cost
One real barrier, and it is cost. Key creation is fully self-serve with no sales call, but the API is exclusive to the Premium plan at $400 a month, above Essential at $62 and Growth at $192. On those two plans the run found no API access.
Every check, and why it scored that way.
The same 27 checks are applied to every platform. What changes is which are N-A and what the core objects mean for that kind of software. Each mark below is quoted from the run's own report.
Category 1 · Functional Coverage
15 / 15Object coverage
weighted coverage = 100%. Every predetermined critical, important, and optional object is present with role-appropriate operations; no critical object absent. [OpenAPI tags: Bank Accounts (42 ops), Leases (28), Lease Transactions (24), Rental Properties (24), Ownership Account Transactions (23), Rental Units (18), Vendors (17), Bills (14), Tasks (14), General Ledger (10); live 2026-08-27: properties 1,613 / units 2,486 / leases 3,441 / tenants 5,633 / bank accounts 14 / GL accounts 70 / vendors 715 / owners 941 / tasks 18,963 / work orders 5,684 / applicants 9,922 all returned 200]
Core operational actions
(documentation-graded) — weighted coverage = 100%. Create/update is documented for every critical mutable workflow: POST /v1/leases + PUT /v1/leases/{leaseId}; lease-ledger POST charges/payments/credits; bank-account checks/deposits/transfers; bills; tasks; work orders. No critical write workflow absent. Writes were not executed live under the read-only safety rule. [OpenAPI POST/PUT paths with request-body schemas, e.g. LeasePostMessage, LeaseChargePostMessage, LeaseLedgerPaymentPostMessage, BankAccountDepositPostMessage]
Delete or lifecycle actions
(documentation-graded) — weighted coverage ≈ 95%. Principal lifecycle changes are documented and broad: renewal, move-out, payment reversal, refunds, reconciliation finalize/clear, deposit withholding, and 14 delete endpoints. No critical lifecycle action absent. [POST /v1/leases/{leaseId}/renewals; LeaseMoveOutDataPostMessage; LeaseLedgerReversePaymentPostMessage; POST .../reconciliations/{id}/finalizerequest]
Change notification
Buildium publishes 91 webhook event types across 32 entities, covering the critical-plus-important state changes (Lease.Created/Updated/Deleted, LeaseTransaction., Payment., Transaction., Rental., RentalUnit., Tenant., BankAccount., Bill., GLAccount., WorkOrder., Task., Vendor., OwnershipAccount, Applicant). Incremental polling via lastupdatedfrom supplements it. [info.description §Webhooks / §Webhook Events]
Category 2 · Design & Reliability
7.5 / 10Modern API conventions
"built upon standard REST conventions ... consistent resource-oriented URLs ... JSON-encoded messages ... standard HTTP status codes and verbs." [info.description §API Overview]
Consistent typing
schemas and live reads agree and are type-consistent. Money is numeric, not stringly typed. [Schemas: BankAccountMessage.Balance number/double, LeaseTransactionMessage.TotalAmount number/double; live 2026-08-27: Balance=40245.91 (float), TotalAmount=149.9 (float), IsDefaultGLAccount=true (bool), ids integer]
Structured errors
errors return a structured JSON body (UserMessage, ErrorCode, Errors[]) with correct HTTP status semantics and a usable human message, but the machine-readable ErrorCode is not populated. Live 2026-08-27: 404 → {"UserMessage":"No property found with the id.","ErrorCode":null,"Errors":[]}; 401 and 400 likewise returned ErrorCode:null, Errors:[]. Limitation: no populated, stable machine code to branch on. [Schema ApiErrorResponse; info.description §Response Codes; live battery step 4]
Duplicate prevention
(documentation-graded) — no request idempotency key or equivalent is documented for consequential writes (payments, charges, deposits). The only idempotency guidance is for webhook consumers ("make your event processing idempotent"), not for API requests. Consequential POST retries can create duplicates. [info.description §Webhooks/Best Practices; term "idempoten" appears once in the spec, in the webhook-consumer context only]
Graceful handling under load
documented 429 plus explicit numeric backoff guidance ("retry ... after a short interval (~200ms)"; "exponential backoff"). Limit stated as 10 concurrent requests per second. [info.description §Rate Limiting; §Response Codes]
Pagination for large collections
documented limit/offset (default 50, max 1000), total-count signal X-Total-Count, and stable-ordering guidance ("sort on a unique property such as Id"). Verified live: pages disjoint, X-Total-Count=1613 stable across pages. [info.description §Pagination / §Sorting Results; live battery step 2]
Bulk or incremental export
full datasets can be pulled without per-record calls via list + limit/offset pagination, and incremental sync via lastupdatedfrom/updateddatetimefrom is available on many resources (leases, tenants, owners, vendors, tasks, work orders, rentals). But there is no dedicated bulk/export path (no async export jobs or bulk endpoints), and updated-since filters are absent on several core resources — bank accounts (0/11 list endpoints), bills (0/3), most general-ledger and lease-transaction list endpoints. Live: leases?lastupdatedfrom=2026-01-01 honored (X-Total-Count=635). [info.description §Bulk Request Options; OpenAPI query-parameter survey]
Webhook security and delivery reliability
(documentation-graded delivery) — signed payloads (HMAC-SHA256 via buildium-webhook-signature + buildium-webhook-timestamp), a documented retry policy (retries at 1 minute, 10 minutes, 1 hour; suspension after 20 consecutive failures), and consumer replay/idempotency guidance. Round-trip delivery not executed live. [info.description §Webhooks/Receiving Callbacks, /Signature Checks, /Best Practices]
Concurrency and conflict control
a 409 Conflict response is documented and appears on 26 write operations (e.g. update bill, create bill payment, finalize reconciliation, create ownership account), and a concurrency limit is stated (10 concurrent requests/second). But there is no optimistic-concurrency mechanism — no ETag/If-Match and no version/row-version fields (0 occurrences) — so two concurrent updates can silently overwrite each other (last-write-wins). The 409 is a generic state-conflict, not a concurrency token. [info.description §Response Codes (409); OpenAPI response survey; absence of ETag/If-Match]
Versioning and backward compatibility
explicit major version in the path (/v1/), a documented backward-compatible vs backwards-incompatible change policy with advance notice, and concrete deprecation windows (appliance endpoints deprecated in favor of Inventory & Assets, "will start returning 410 Gone on 2026-10-19", with successor endpoints mapped; 16 operations already carry 410). [info.description §API Versioning; §Changelog/Deprecations 2026-07-21]
Request traceability
every response carries a unique identifier (x-amzn-RequestId, X-Amzn-Trace-Id), but these are AWS-infrastructure headers, not a Buildium-documented request/correlation ID, and Buildium's support form asks for date/URL/status/response body rather than a request identifier. Present but undocumented and not clearly usable with support. [Live battery step 5 headers 2026-08-27; info.description §Support]
Service availability and status transparency
public status page with incident history and uptime percentages. status.buildium.com/uptime (Atlassian Statuspage) showed Buildium Platform uptime June 2026 100%, July 2026 99.94%, August 2026 100%, with an Incidents/history tab. [status.buildium.com/uptime and /history, observed 2026-08-27]
Category 3 · Access Control
5 / 5Read-only credentials
"You can restrict a key ... to read-only access (GET resources only)." [info.description §Keeping API Keys Safe]
Scoped credentials
key creation lets you "choose which pieces of Buildium data you want this API key to have access to by marking the corresponding checkboxes," and keys can be restricted "to particular Buildium entities." Fine-grained resource/action scoping. [info.description §Creating API Keys step 5; §Keeping API Keys Safe]
Multiple keys
the key-creation flow and management page describe naming keys so you can "locate the right key when you make a request," i.e. multiple distinct keys per account. [info.description §Creating API Keys]
Rotation and revocation
self-serve delete ("delete this key and start from scratch") and rotation ("regularly recreate your client IDs and secrets from your Buildium account") in Developer Tools. [info.description §Creating API Keys; §Keeping API Keys Safe]
Test and production isolation
a separate sandbox environment (https://apisandbox.buildium.com/) with isolated data, and keys are environment-bound: "Can I use my production keys to access my sandbox? No ... the API keys are restricted to the environment they were created in." [info.description §API Sandbox / §Accessing the Sandbox / FAQs]
Category 4 · Docs & AI-Ready
3.75 / 5Complete self-serve reference
a complete, public (no login) reference at developer.buildium.com rendered with ReDoc, covering authentication, every endpoint, parameters, and per-operation "Request samples"/"Response samples" bodies, plus a worked first-request walkthrough. Minor limitation: response samples are schema-generated placeholders rather than curated realistic values. [developer.buildium.com, observed 2026-08-27 (Request/Response sample panels confirmed in DOM); info.description §How to Make a Request]
Reliable machine-consumable integration path
a complete, maintained OpenAPI 3.0.4 specification (298 paths, 462 operations) is published and downloadable ("Download OpenAPI specification" on developer.buildium.com). Sufficient for code and tool generation. [frozen spec evidence/buildium-openapi-v1-frozen-2026-08-27.json; developer.buildium.com Download control]
AI-readable documentation
no llms.txt, llms-full.txt, per-endpoint Markdown, or downloadable Markdown documentation corpus is published. Both developer.buildium.com/llms.txt and /llms-full.txt return S3 "AccessDenied" (object absent), confirmed in a rendered browser on 2026-08-27. (The OpenAPI spec — machine-readable and carrying a rich embedded Markdown guide — is credited under C4.2, not here.) [rendered-browser checks 2026-08-27]
Kept current
a detailed changelog runs monthly from 2020-07 through 2026-08-18 (nine days before this run), including API Updates and dated Deprecations. [info.description §Changelog]
Category 5 · Access & Cost
7.5 / 15Self-serve API key
once the account is entitled, an administrator enables the Open API and self-creates keys at Settings → Developer Tools → Create API Key, with no sales call, ticket, or key-approval step. [info.description §Enabling the API / §Creating API Keys]
Not commercially gated
API access is locked to the top-tier plan. The guide states "To take advantage of the Buildium Open API you must have a Premium Subscription," and the pricing page lists "Open API" as exclusive to Premium ($400/month), above Essential ($62) and Growth ($192). [info.description §Getting Started note; www.buildium.com/pricing, observed 2026-08-27]
What works
- The most complete object coverage of any API graded so far
- A real sandbox, with keys that cannot reach production data
- Read-only and per-resource scoped keys, self-serve
- 91 webhook event types across 32 entities
- Changelog running monthly since 2020
What to watch
- Buildium's pricing page lists the API as Premium-plan only, $400/month
- No idempotency keys, so a retried payment can post twice
- Error responses never populate a machine-readable code
- No optimistic concurrency, so two writers can silently overwrite
The bottom line for a property manager
Buildium's Open API is one of the most complete property management APIs you can build on today. It is a modern, well typed, versioned REST API with clear docs, a downloadable OpenAPI file, a sandbox, safe read-only keys, and a public status page. Its weak spots are all in money-safe automation: guard against double-posting a retried payment yourself, because the API will not. The biggest practical barrier is cost rather than capability, since the API is Premium-plan only. Buildium is not a bank, and moving money still depends on its ePay add-on and the underlying banks.
Check it yourself.
Both files behind this page, in full.
Buildium’s full report
The complete markdown report this page is built from, including the evidence packet, the run metadata and every check in full.
Download the Buildium reportThe grading file
The exact rubric behind every score on this page. Same file, every platform. Run it yourself and compare.
Download the methodologyFound a factual error in your grade?
Tell us and we will fix it. Every mark on this page traces to a specific piece of first-party evidence or a live API call, and the full report is published so you can see exactly what was checked and what it was checked against.
Confirmed factual errors are corrected immediately.
Everything else waits. We do not rescore piecemeal on request, because a board where some vendors have been re-run and others have not is not a fair comparison. Shipped improvements, changed documentation and disagreements about judgement all go into the next full rerun.
Contact us with a factual errorMethodology inspired by SaaStr’s AI Agent API Report Card. Sponsored by Column.