API Report Card · Listings, Applications & Tenant Screening · Methodology v1.1
Boom
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
You can run the whole screening funnel from your own code: create a lead, turn it into an application, pull the credit, criminal, eviction and income reports, read Boom's recommendation, approve or reject with your own reasons, and have Boom push the approved applicant into your PMS. You can also enroll residents in rent reporting, keep lease terms current, and close them out at move-out. What you cannot do is manage a lease, since there is no lease record here at all, configure the screening rules, upload or sign a document, or undo a decision through the API even though a person can do it in the portal. Plan on a person in the Boom portal for setup and reversals, and your code for everything in between.
2 · Design & Reliability
The API works, and the parts you touch first are pleasant: clean REST, real pagination with totals that survived a repeat-and-overlap test, validation errors that name the offending field, and a status page with genuine incident history. The weakness is everything you need when an integration runs unattended. No request id to quote when something goes wrong, no ETag to stop two jobs overwriting each other, no Retry-After to back off against, and no idempotency key on the call that files rent payments to the credit bureaus. Budget for defensive code: log your own correlation ids, serialize your writes, deduplicate webhooks yourself, and parse what the API actually returns rather than trusting the published rent-reporting schema.
3 · Access Control
The best part of the API and the reason it is safe to automate against at all. You can mint a key that is read-only and limited to a single owner's property group, hand it to an agent, a reporting tool or a third party, watch it in a list with the date and the person who made it, and kill it with one toggle. There is also a real sandbox with its own credentials that cannot reach the credit bureaus. One boundary worth knowing: owner scoping does not reach Boom's own billing objects, so a read-only key can still see your Boom invoices and your payout account details. Scope by what the key is for, and do not treat read-only as harmless.
4 · Docs & AI-Ready
Point your developer, or your coding assistant, at the OpenAPI file on GitHub rather than the documentation site's endpoint pages. The screening spec is accurate, current and complete enough to generate a working client. The rent-reporting half will cost you a day of trial and error: its spec points at the sandbox host, describes form-encoded bodies the live API does not use, and calls numbers and booleans strings. All thirteen endpoint pages in the docs navigation have pointed at a developer's dead tunnel since March 2024. The same warning applies to AI tools, because the AI-readable corpus looks authoritative and will quietly hand an agent an endpoint list that does not exist. The redeeming feature is that Boom clearly maintains this: the changelog is weekly and the spec repo was updated a week before the run.
5 · Access & Cost
If you are already a Boom customer you are minutes from a working key: Settings, API, name it, pick read-only if that is all you need, save. Nobody to ask and no ticket to file. API access is not behind a premium tier and is not separately charged. The gap is transparency rather than cost: there is no pricing page anywhere and every pricing question routes to a sales form, so you cannot see the terms before you ask. Expect to email Boom if you want a sandbox to develop against.
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
7.5 / 15Object coverage
weighted coverage = 75–79% (all three runs computed within this range; the mark is stable across it). Applications and screening decisions present with required operations; lease lifecycle 0.5; documents/e-sign 0.5 (readable via GET /partner/v1/applicants/{id}/additional_documents, not requestable or uploadable, no e-sign anywhere); listings read-only; applicants readable and actionable but not creatable or updatable. No critical object absent. [screening spec /partner/v1/applications, /applications/{id}/applicants/{applicant_id}, /applicants/{id}/additional_documents, /listings; rent-reporting spec /partner/v1/enrollments; live reads of 10 collections 2026-09-03]
Core operational actions
weighted coverage = 65–71% across the three runs. All three critical write workflows at least partially present, so the API is not observational. Documents score 0.0 (read-only where upload is expected); applicants have no create or update; no lease can be created or advanced. Documented but absent from the API: the Screening API page advertises a deployment option where "you can programmatically control the entire BoomScreen workflow, including configuring application settings", while the Quickstart states verification templates "can only be created, updated, and assigned to properties via the Boom Partner Platform (e.g., not programmatically)" — so application cost and decision criteria are portal-only. Documentation-graded. [POST /partner/v1/leads/{lead_id}/apply; POST /applications/{id}/approve (ApproveApplication); POST /applications/{id}/reject (RejectApplication); POST /partner/v1/enrollments, PATCH /enrollments/{id}, POST /enrollments/{id}/enroll]
Delete or lifecycle actions
weighted coverage = 78–80%. The reversal surface is rich: uncancel alongside cancel, resume alongside place_on_hold, merge and split, expire on an identity verification, plus move-out and unenrollment. Three gaps hold it under 0.85: no endpoint reverses a decision (the webhook application_decision_reverted and a portal "undo decision timeframe" exist, but no API path performs it), no endpoint voids or deletes a document, and there is no lease to terminate. Documentation-graded. [screening spec /applications/{id}/{approve,reject,cancel,uncancel,place_on_hold,resume,merge,split}, /applications/{id}/applicants/{applicant_id}/{cancel,uncancel,override_identity}, /leads/{lead_id}/verifications/identity/expire, PATCH /magic_links/{id}; rent-reporting spec DELETE /enrollments/{enrollment_id}, PATCH with moved_out_date]
Change notification
push coverage = 73–75% weighted; ceiling 84.6%. The event catalogue is large (application started/submitted/updated/under review/approved/conditionally approved/declined/canceled/merged/decision reverted; applicant started/submitted; identity verification finished/expired; PMS push; note added; and on reporting: customer registered, enrollment pending/approved/rejected, customer unenrolled with reason codes, furnishment finished, rental payment verified, issue pending/resolved, enrollment moved out). But documents/e-sign is an important object carrying weight 2 of the 13 weighted critical-plus-important state changes and has no events at all, so the maximum reachable coverage is 11 ÷ 13 = 84.6% — below the 0.85 bar even if every other item scores 1.0. Polling is thin: last_updated_from_date/last_updated_to_date exist only on /applications, with date ranges on the activity logs and billing; properties, units, leads, customers, enrollments, listings and magic links expose no updated-since filter. [docs /webhooks; screening spec /partner/v1/applications query parameters; live test confirmed last_updated_from_date accepted]
Category 2 · Design & Reliability
5 / 10Modern API conventions
resource-oriented REST, standard verbs, JSON, bearer auth, correct status semantics observed live. [docs Overview: "the Boom API is organized around REST…predictable resource-oriented URLs…returns JSON-encoded responses, and uses standard HTTP response codes, authentication, and verbs"; confirmed live across 10 collections and 11 error conditions]
Consistent typing
both failure conditions met, on core fields. Schema vs live: the rent-reporting spec declares monthly_rent_amount as string (live returns float), monthly_rent_day_of_month as string (int), lease_month_to_month as string (bool), issues as string (array), and lat/lng as string (float) while declaring the same request parameters integer, boolean and number; months_delinquency is typed string where the webhook sends a number. Same concept, different types across endpoints: monthly rent is {cents, currency} on /partner/v1/units and on balance of /partner/v1/billing/statements, but a bare float on /partner/v1/enrollments — same host, prefix and credential. Envelope inconsistency: nine of ten collections return has_more; /partner/v1/applications returns last_page, contradicting its own allOf: [PaginatedResponse, …] composition where has_more is required. One endpoint, two content types: POST /partner/v1/authenticate is application/json in the screening spec and formData in the rent-reporting spec. [rent-reporting spec definitions Boom_PartnerAPI_ReportingAccount_Enrollment_BaseEntity, Boom_Service_Entities_Address, Boom_PartnerAPI_ReportingAccount_RentalVerification_BaseEntity; screening spec PaginatedResponse; live reads 2026-09-03]
Structured errors
correct HTTP semantics with populated stable machine codes on the main paths: {"error":{"message":"Not Found","status":404,"code":"not_found"}} and {"error":{"errors":[…],"message":"…","status":400,"code":"validation_error"}}. Exact limitation: shapes vary. The 401 omits code entirely ({"error":{"message":"Unauthorized","status":401}}) despite the spec declaring code required on that schema; an unknown path returns plain-text 404 Not Found, not JSON; TooManyRequestsResponse types error as a bare string where every other error schema uses an object; and the rent-reporting spec attaches no error schema to any 400/401/404/422. Also: malformed JSON on the auth endpoint returns HTTP 400 with code: "api_error" and the message "An internal error occurred of type…", presenting a caller mistake as a server fault. [live: 11 deliberate error conditions 2026-09-03; screening spec ValidatorResponse, NotFoundResponse, ForbiddenErrorResponse, InternalErrorResponse, TooManyRequestsResponse, ErrorResponse]
Duplicate prevention
no idempotency mechanism documented anywhere (zero occurrences across both specs, the 130 KB corpus and the changelog). Protection covers a meaningful subset through natural idempotency: POST /partner/v1/enrollments returns documented 400 "Customer already have active enrollment", and customer "email and phone must be unique, meaning neither element should be present in Boom's system". Exact limitation: the consequential writes have none — POST /enrollments/{id}/report_rental_payments (furnishes to three bureaus), POST /applications/{id}/approve and /reject (charge fees, email real applicants), POST /leads/bulk (up to 100 records). Documentation-graded; battery step 7 is N-A.
Graceful handling under load
429 documented as a modelled response on 47 of 61 screening operations with a TooManyRequestsResponse body. Exact limitation: no recovery guidance — no Retry-After in either spec, none observed on any of 30+ live responses, no numeric backoff guidance anywhere (the sole "rate limiting" mention in the corpus concerns contact-form spam protection), and the rent-reporting spec documents no 429 at all. Rate-limit exhaustion deliberately not forced against production.
Pagination for large collections
documented offset pagination (page, per_page) with a strong total-count signal (total_count, page_count, current_page, has_more, all four required by PaginatedResponse). Live: page 1 repeatable in identical order, page 1 vs page 2 zero overlap, per_page=1000 returned a several-hundred-record collection whole with no cap encountered. Exact limitation: no stable ordering guarantee is documented (ordering controls exist on one endpoint only — order_by/order_direction on rent-reporting /customers); the per-page ceiling is undocumented, which the check names explicitly; and the envelope is inconsistent (/applications returns last_page; the rent-reporting spec documents bare {"items":[…]} with no count or next signal). [live repeatability, overlap and cap probes 2026-09-03]
Bulk or incremental export
full datasets obtainable without per-record calls (an entire collection in one per_page=1000 response; list endpoints return complete objects). Exact limitation: no dedicated bulk or export path (POST /leads/bulk is a bulk create), and incremental sync reaches only applications, activity logs and billing. Properties, units, listings, leads, customers, enrollments and magic links carry updated_at but expose no updated-since filter, so warehouse sync means re-reading them whole.
Webhook security and delivery reliability
two of three elements present. Retry policy documented: "If your server returns a non-2xx status or is unreachable, we retry 2 times at 1 minute intervals." Verification present but weak: "Each webhook request can include an x-api-key header with the secret token configured for your webhook endpoint" — a static shared secret, not an HMAC; no payload integrity, replayable, and conditionally worded. Replay/idempotency guidance absent: every payload carries a unique request_id, but nothing instructs consumers to deduplicate on it. Note also that the webhooks page says URLs are "configured per partner — contact support", while the changelog for 2026-08-26 says "To subscribe, open Settings → Webhooks and add your URL" — the documentation is stale. Documentation-graded; step 8 not run.
Concurrency and conflict control
neither mechanism. No ETag or Last-Modified on any live response including single-resource reads; no If-Match or conditional-request support documented; no version, revision or lock field on any entity; 409 appears nowhere across 86 operations. Two integrations writing the same record will silently overwrite one another. [zero matches across both specs and the corpus; live header capture 2026-09-03]
Versioning and backward compatibility
explicit version identifier in the path (/partner/v1/, /crm/v1/) on all 65 paths, plus info.version in both specs. Exact limitation: no document defines breaking versus non-breaking changes, states a deprecation window, or commits to a notice period; the only deprecation signalling is four webhook events labelled "(Deprecated)" inline with no removal date; the docs repository publishes no releases and no tags. (Versioning contract only; currency graded in C4.4.)
Request traceability
no request or correlation identifier on successful responses; the complete live 200 header set is Date, Content-Type, Transfer-Encoding, Connection, Set-Cookie, Vary, Cache-Control. An identifier exists on part of the error surface: error_id (UUID) and error_signature, observed live and documented in InternalErrorResponse. Exact limitation: confined to the api_error class, absent from 401, 404, validation failures and every success, not in the schema's required list, and never documented as a reference to quote to support.
Service availability and status transparency
public status page with both required elements: 11 named components including API, BoomScreen and BoomReport; nine resolved incidents 2026-02-04 to 2026-05-19 (two platform outages, a Rent Manager sync failure, an application-submission fault), each with 2–5 updates; per-component uptime percentages over a trailing window for the showcased Portal and API components, tracking from 2025-11-01. Minor drift: the changelog points to status.boompay.app, which does not resolve; the working address is boompay.statuspage.io. [statuspage summary/incidents/components JSON; changelog 2026-03-24]
Category 3 · Access Control
5 / 5Read-only credentials
the Create API key dialog presents an Access type selector with exactly two options, "Read and write" and "Read-only"; Boom describes the effect as restricting the key "to GET requests only". [operator screenshot of portal.boompay.app/settings/api with the Access type menu open, 2026-09-03; changelog "Read-only API access", 2026-03-31]
Scoped credentials
fine-grained resource and action scoping. The same dialog carries Owners and Property groups multi-selects; "when a scoped API key is used, it only returns data associated with the assigned owners or property groups". A separate per-user role model with ~20 named permissions sits alongside it. Boundary worth knowing: scoping is organised around owners and property groups; account-level resources such as bank_accounts and billing are not owner-scoped, so a read-only key can still read Boom billing statements and the nickname, routing number and last four of the linked payout account. [operator screenshot 2026-09-03; changelog "Scoped API keys", 2026-03-31; live reads of /partner/v1/bank_accounts and /partner/v1/users]
Multiple keys
the API Keys screen lists multiple concurrently active keys, each with its own name, creator and creation timestamp; two were present and enabled, created seventeen months apart, with a "New API" control on the same page. [operator screenshot 2026-09-03]
Rotation and revocation
, self-serve — each key row carries an enable/disable toggle and a delete control; secrets can be regenerated in place, and Boom added a confirmation modal in April 2026 because the action is destructive ("Regenerating your API secret key will break any active integration using it"). Secrets are shown once and are non-recoverable. [operator screenshots 2026-09-03; changelog "API key regeneration warning", 2026-04-08]
Test and production isolation
separate environments with separate credentials, documented down to distinct portal, API and SDK hosts; operators are instructed to "make sure you have access to Sandbox and Production, and generate keys in both places". Isolation is stated at the credential level and, critically for this product, at the regulatory level: "You can use the Boom API in Sandbox mode, which doesn't affect your live data or interact with other credit bureaus or consumer reporting agencies. The API key you use to authenticate the request determines whether the request is Live mode or Sandbox mode." Documentation-evidenced only — no sandbox credential was available, so isolation was not exercised live. [docs /environments, Overview, /z1wr-authentication]
Category 4 · Docs & AI-Ready
3.1 / 5Complete self-serve reference
the prose documentation is public and genuinely useful: authentication explained with worked cURL, both quickstarts carrying runnable request bodies, a complete status dictionary, and a webhooks page documenting each BoomReport event with a full JSON payload and the note that amounts are in cents. Exact limitations: all thirteen endpoint pages in the documentation navigation are unusable — every one names its base URL as an expired ngrok tunnel (5739-2607-fb91-…ngrok-free.app/api/admin/v1/…, created 2024-03-27), every one carries "jsonExample": "", and the /admin/v1/ family they describe appears in neither published specification; the two "API reference" pages contain nothing but a jsonFileLocation pointer to raw GitHub; the rent-reporting spec contains zero response examples and zero operation summaries, so the BoomReport half has no worked response example anywhere; and several instructions are stale (keys said to live under "Settings → Developers" when the screen is "Settings → API"; webhook setup said to require support when the changelog says self-serve). Documented capabilities with no published endpoint include the "applicant experience" submission API, document requests, and webhook subscription management. [all 13 endpoint pages retrieved as Markdown 2026-09-03]
Reliable machine-consumable integration path
the screening specification is strong: OpenAPI 3.0.0, 49 paths / 61 operations, 126 schemas, both servers declared, modelled error responses, hundreds of field examples, every $ref resolving, repository last pushed 2026-08-27. Exact limitation: no single mechanism covers the API. The screening spec covers a limited subset (it omits all 16 rent-reporting paths); the rent-reporting spec covers those but would generate a materially wrong client — host: api.sandbox.boompay.app with no production entry (and api.boompay.app does not resolve), formData where the live endpoint accepts application/json, string types for numeric, boolean and array fields, and list responses documented without the pagination envelope the API returns. That is substantial manual correction. Smaller warts: the screening spec reuses one operationId (ApplicationsController_findReport) across two operations, breaking strict generators. @boompay/screening on npm (v1.3.0, 2026-06-10, nine releases) is a React component library for embedding applicant and identity flows, not an API client, so it is recorded but does not satisfy the check. No MCP server evidenced.
AI-readable documentation
qualifying first-party resources exist and are well formed: docs.boompay.app/llms.txt indexes every page, llms-full.txt is a 130,425-byte Markdown corpus of all 43 pages, and each page is retrievable as <slug>.md. Exact limitation: the corpus represents only a fraction of the API — 12 distinct /partner/v1/ paths appear anywhere in it against 65 in the specifications, the endpoint-level content it does contain is the thirteen broken ngrok pages, and the specifications themselves sit outside the corpus behind GitHub pointers. An AI coding tool fed llms-full.txt would come away with an /admin/v1/ family that does not exist and would miss most of the API. Separately, www.boompay.app/llms.txt is not documentation at all — it contains robots-style crawler directives for GPTBot, ClaudeBot, Google-Extended, PerplexityBot, CCBot and YouBot.
Kept current
two independent, current mechanisms. The product changelog publishes at roughly weekly cadence with its most recent entry dated 2026-09-02, the day before this run, and more than ninety dated entries back to March 2026, tagged by product, calling out API changes specifically ("Scoped API keys", "Read-only API access", "Activity log via API" 2026-03-31; "API key regeneration warning" 2026-04-08; "Webhook for notes added to an application" 2026-08-26). The specification repository is a second, finer-grained record with dated, descriptive commits through 2026-08-27 ("add GET /partner/v1/listings endpoint", "fix: screening applications status query param as array (status[])", "docs: add verification_last_updated_at field to Lead schema"). Deprecated webhook events are marked inline. (Currency of change communication only; the versioning contract is graded in C2.10, and the stale endpoint pages are penalised in C4.1 — not counted twice here.)
Category 5 · Access & Cost
15 / 15Self-serve API key
directly observed, unanimous across all three runs. The account owner, a property manager rather than a software partner, created a working production key from Settings → API in their own account at 10:59 on the morning of the run, and it authenticated against the production host minutes later. Creation is a form with a name, an access type, optional scopes and a Save button — no sales call, no ticket, no approval step. Boom's documentation describes a slower route ("Fill out the 'Request API documentation' form… Your request will be reviewed, and you will be emailed and invited to a Sandbox and Production Boom Partner Platform"), but that governs partner onboarding and sandbox provisioning, not credential issuance in an existing account; the entitlement question it raises is scored in C5.3. [operator screenshots 2026-09-03; live authentication 18:25 UTC]
Not commercially gated
no evidence of a premium-plan gate exists: Boom publishes no plan tiers, a changelog sweep for tier, upgrade and add-on language returns only screening product add-ons (TransUnion ResidentScore, Persona TIN verification) with no API entitlement attached, scoped and read-only keys are presented as general platform capabilities without plan qualification, and an ordinary property-management account has held an API key since April 2025. Recorded for transparency, not scored against the check: Boom publishes no pricing — a 119-URL sitemap with no pricing page, /pricing returning 404, every pricing question routed to a sales Typeform — so an operator cannot learn the cost without contacting sales. That is an opacity problem, not a commercial gate, and C5.3 asks only whether access is included or free. The account owner has confirmed they were not charged extra for API access. Two adjacent capabilities are also vendor-gated rather than self-serve: sandbox access requires the request form and an invitation, and enhanced-security JWT verification requires contacting Boom. Neither is identity or regulatory verification, so neither is excluded on those grounds. [www.boompay.app sitemap; /legal; docs /support, /z1wr-authentication; operator statement 2026-09-03]
What works
- Read-only keys scoped to specific owners or property groups, which is unusual in this category
- Multiple named keys with creator and date, each revocable by you with one toggle
- A real sandbox with separate credentials that cannot reach the credit bureaus
- The whole screening funnel is scriptable, from lead to decision to PMS push
- A public status page with 11 components and nine resolved incidents
- A weekly changelog current to the day before the run, plus a spec repo with dated commits
- The screening OpenAPI spec is accurate and complete enough to generate a working client
- Pagination with real total counts, verified repeatable and non-overlapping live
What to watch
- No pricing published anywhere, so you cannot see terms before contacting sales
- The rent-reporting spec disagrees with the live API on rent amounts, booleans and arrays
- All thirteen endpoint pages in the docs point at a developer's dead tunnel from March 2024
- No idempotency on the call that files rent payments to three credit bureaus
- No concurrency control, so two jobs can silently overwrite each other
- No request id on any successful response, so there is nothing to quote to support
- No Retry-After on any response, even though a 429 is documented
- No lease record, no document upload and no e-signature anywhere in the API
- No endpoint reverses a decision, though a person can undo one in the portal
- Owner scoping does not cover billing, so a read-only key can still read payout account details
The bottom line for a property manager
You can build real automation on the screening half today: pull applications with their credit, criminal, eviction and income reports, decide with your own criteria, and push approved applicants into your PMS. You can enroll residents in rent reporting too. But there is no lease record, no document upload and no e-signature anywhere in this API, so approval is where Boom stops and your system of record begins. Its biggest strength is access control: read-only keys scoped to a single owner's property group, plus a sandbox that cannot touch the credit bureaus, make this genuinely safe to hand to an AI agent or an outside vendor. Its biggest limitation is that the rent-reporting half is unreliable to build against. The published schema disagrees with what the endpoint actually returns on rent amounts and booleans, the documentation's endpoint pages have pointed at a dead developer tunnel since March 2024, and there is no request id, concurrency control, retry guidance or idempotency key for unattended jobs. Boom is not a bank, no first-party material names any bank, processor or money transmitter behind it, and it documents no trust-accounting, client-fund, security-deposit or escrow workflow. Its financial endpoints concern Boom's own billing to you, not money you hold for owners. The score reflects a narrow API with unreliable documentation rather than a weak product: treat Boom as a screening and credit-reporting layer beside your PMS, your trust accounting and your bank rather than a replacement for any of them.
Check it yourself.
Both files behind this page, in full.
Boom’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 Boom 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.