API Report Card · PM Software · Methodology v1.1
Rentvine
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
The strongest part of the API and the reason it is worth building on. Essentially everything your business runs on is reachable: properties, units, leases, tenants, owners, work orders, bills, screening, and the full trust ledger, and most of it can be created and changed, not just read. Three gaps matter. The API can post money to a lease but cannot take it back: there is no way to void or reverse a charge or payment, even though Rentvine can void a bill or a deposit. You cannot post a journal entry or add a general-ledger account, so accounting corrections stay manual. And change notifications are lopsided, firing for properties, units, leases and work orders but never when money moves.
2 · Design & Reliability
This is where the API is weakest, and it is the part that decides how much maintenance your automations need. Paging through big lists works properly, and four export endpoints let you pull leases, properties, units and applications and then fetch only what changed. The problems are the unglamorous kind that cause 2am failures. Every number and yes-or-no value arrives as text, and Rentvine's own published blueprint says some of them are numbers, so code generated from it misreads your core records. Failures come back in five different formats, one of them a bare sentence and one a blank server error, and a missing property returns the wrong kind of error. No rate limit is published. Nothing stops a retried charge from posting twice, or two of your tools from silently overwriting each other on the same lease. There is no version contract and no status page.
3 · Access Control
Full marks, and genuinely good news for anyone pointing an AI agent at their data. You can create a separate key for every tool you connect, give each one only the permissions it actually needs including view-only, and restrict it to part of your portfolio. The permissions are specific enough that Rentvine's own documentation names which one each operation needs, right down to Add Charge. If a vendor relationship ends or a key leaks, you regenerate the secret or delete the key yourself in seconds. The one real absence is a practice environment: there is no sandbox, so any testing happens in your live account.
4 · Docs & AI-Ready
The documentation is better than most property management software offers and it is completely public, with no login and no sales call, and each endpoint explains what it is for and which permission it needs. But it is not something to hand an AI coding tool and trust blindly. Parts of the API are missing from it entirely: bank accounts work but are undocumented, and webhooks are described only in the customer help articles. Some of what it says is wrong, including 26 endpoints it points developers at that do not exist. Expect a developer or an AI assistant to get roughly 80% of the way from the docs and to discover the rest by testing against your live account.
5 · Access & Cost
Full marks, and this is the check most property management vendors fail. You are already paying for the API. It is in the one plan at no extra cost, with no premium tier to unlock and no integration fee, and you can issue your own key in about two minutes without asking anyone. For an operator who wants to build their own tools, getting in the door immediately and at no marginal cost is worth a great deal.
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
9.4 / 15Object coverage
weighted coverage 85.5% (32.5 of 38 weight), no critical object absent. Critical: properties 1.0, units 1.0, leases 1.0, tenants 1.0, lease transactions 1.0, general ledger 0.5, bank accounts 0.5 (present and readable but undocumented and carrying no balance field). Important: owners 1.0, bills 1.0, payments 1.0, applicants 0.5 (no create), work orders 1.0, reconciliation 0.5 (deposit-level only). Optional: files 0.5 (upload only), communications 1.0, custom fields 1.0, associations 1.0, inventory 1.0. [Live 2026-09-02: /accounting/bank-accounts → 200 with 2 records; /accounting/accounts → 200 with 92; /accounting/transactions/search → 200 with Pagination-Total-Items: 36328; /maintenance/work-orders → 1534; /tenants → 363; /owners → 156]
Core operational actions
weighted coverage 86.8% (33 of 38 weight), no critical write workflow absent. All three critical workflows present. General ledger writes 0.0 (absent); applicants 0.5; reconciliation 0.5. [docs.rentvine.com POST /accounting/leases/{leaseID}/charges, /payments, POST /leases, POST /leases/{leaseID}; live-verified write 2026-09-02: POST /maintenance/materials → 200 {"material":{"materialID":"1",...}}, then POST /maintenance/materials/1 → 200 with description changed and dateTimeModified advanced from 20:07:17 to 20:07:19] — ledger and lease writes documentation-graded.
Delete or lifecycle actions
weighted coverage 86.2% (25 of 29 weight), but a critical lifecycle action is absent, which the check scores as no irrespective of the percentage. Eleven of thirteen lifecycle changes are present, including void for bills and deposits — but voiding or reversing a posted lease-ledger charge or payment is not exposed, and neither is payment refund/return. [Verified by exhaustive search: no path or request body exposes transaction void; contrast DELETE /accounting/{billID} "Void Bill" and DELETE /accounting/deposits/{depositID} "Void Deposit", which establish that the platform has the concept. Live-verified: DELETE /maintenance/materials/1 → 200, record isDeleted: 1 and absent from listings.]
Change notification
push coverage is 33.3% (11 of 33 weight), below the 0.50 push floor, so partial is earned on the polling branch rather than the push branch. Webhooks fire on Create or Update for four object types only — Properties, Units, Leases, Work Orders — so no event exists for the money-side changes (transactions, charges, payments, bills, deposits, statements) or for screening applications. Incremental polling is genuinely efficient and covers the critical changes: dateTimeModifiedMin/Max are offered on 17 operations including /accounting/transactions/search, /accounting/transactions/entries/search, and /accounting/journal-entries/search. [help.rentvine.com 16603326; 16574284; components.parameters.date_time_modified_min. Live-verified: /properties/search returned 175 unfiltered, 127 with dateTimeModifiedMin=2026-08-01T00:00:00, and 0 with 2030-01-01T00:00:00 — the filter is honoured.]
Category 2 · Design & Reliability
2.5 / 10Modern API conventions
Resource-oriented JSON REST over HTTPS, live-verified, and entirely interoperable in practice, but the conventions are mixed. The exact limitations: there is no PUT or PATCH anywhere in 205 operations — POST does double duty as update (POST /leases/{leaseID} is summarised "Update Lease"); DELETE is semantically overloaded to mean void rather than delete for financial objects (DELETE /accounting/{billID} = "Void Bill", DELETE /accounting/deposits/{depositID} = "Void Deposit"); the bills resource sits at the malformed path /accounting/{billID} — a bare account-level path — while bills are created at /accounting/bills, so read, update, and void of a bill live outside the collection that creates it; and two declared paths (/leases/{leaseID}/pets, /leases/{leaseID}/pets/{id}) carry no operations at all because their $refs point to unpublished files.
Consistent typing
Core fields are stringly typed and types vary across endpoints, across operations on the same record, and against the published schema. Live 2026-09-02: identifiers, booleans, money, and coordinates all return as JSON strings — "propertyID":"69", "portfolioID":"76", "isActive":"1", "isMultiUnit":"0", "leaseID":"117", "rent":"3100.00", "beds":"4", "latitude":"33.84332090". The specification contradicts this: components.schemas.lease.leaseID and lease.propertyID are declared "type": "integer" while the live API returns "117" and "180" as strings, so generated clients mis-parse the core object. The same field is typed differently in different schemas — propertyID is integer in lease but string in unit. Within a single resource, the same field changes type between operations: material.isDeleted returned "0" (string) from POST /maintenance/materials and 1 (integer) from DELETE /maintenance/materials/1. Even the error code field varies: integer 401 on one path, string "404" on another. Timestamps are not ISO-8601: "dateTimeCreated":"2025-07-22 16:01:03" (space separator, no timezone).
Structured errors
Failures return a JSON body with a human-readable message and, in the common cases, a correct HTTP status, which an integration can act on. The exact limitations: there is no populated stable machine-readable error code — the specification defines only {"error": string} (three error responses, error_400/401/403), and where a code field does appear it merely mirrors the HTTP status and its type is inconsistent (integer 401 vs string "404"); error shapes vary across endpoints, with five distinct shapes observed live — {"code":401,"error":"Access Denied"}, {"code":"404","error":"Not Found","message":"..."}, {"error":"Property 99999999 not found"}, {"error":"invalid input."}, and the field-keyed {"sellPrice":["Sell Price cannot equal to 0.00"]}; status semantics are wrong in at least one case (HTTP 400 returned for a not-found property); and two responses were not parseable at all — the documented endpoint GET /accounting/ledgers returned HTTP 400 with the bare JSON string "Search Failed", and GET /properties?page=notanumber&pageSize=abc returned HTTP 500 with a completely empty body. No 429, 409, or 5xx response is documented on any of the 205 operations. (Run 1 graded this no on the strength of the two unparseable responses; resolved to partial — see "Three-run reconciliation".)
Duplicate prevention
No idempotency mechanism is documented: idempoten occurs zero times in the specification, and no unique-request-identifier convention exists. Live 2026-09-02, an Idempotency-Key request header had no effect on behaviour. The consequential writes — POST /accounting/leases/{leaseID}/charges, /payments, /accounting/other-payments, and the bill and deposit creates — carry no documented duplicate protection, so a retried or double-submitted charge risks posting twice to a real trust ledger with no API-side way to void it (C1.3). The one protection observed was incidental natural uniqueness on a catalog record: a second identical POST /maintenance/materials returned {"name":["A material already exists with this name"]} — an undocumented name constraint on one optional resource that does not extend to the financial writes this check concerns. Consequential-write behaviour documentation-graded.*
Graceful handling under load
No 429 response is documented on any operation, no rate limit is described in any first-party source, and a full header survey of live 200 responses returned no rate-limit, quota, or Retry-After header of any kind. No numeric backoff guidance is published. The only throttling language in first-party materials concerns Plaid's own practices, not the Rentvine API. Rate limits were not deliberately exceeded, as doing so would risk disrupting a production account; the mark rests on documented absence, not on an untested limit.
Pagination for large collections
Pagination is well built and live-verified. Eight pagination response headers are documented and populated: live 2026-09-02, GET /properties?page=1&pageSize=5 returned Pagination-Total-Items: 128, Pagination-Total-Pages: 26, Pagination-Next-Page: 2, plus page-size, current-, before-, first-, and last-page. Pages 1 and 2 were fully disjoint and a repeated request for page 1 returned an identical order, so an entire large collection is traversable in practice. The exact limitations: ordering is documented on only 11–13 GET operations and is not documented for /properties, /leases, /tenants, or /accounting/transactions/search (36,328 rows), so a consumer of the core collections has an observed but unguaranteed ordering, with the attendant risk of skipped or duplicated rows during concurrent writes; the page-size cap is stated only as "Maximum page size is enforced server-side" with no number; and components.parameters.page_size_25 declares default: 25 while the GET /properties description that uses it says "Default page size is 15."
Bulk or incremental export
Dedicated export endpoints exist and work, but coverage is incomplete. GET /leases/export, /properties/export, /properties/units/export, and /screening/applications/export all accept dateTimeModifiedMin/Max plus pagination, and were live-verified (190, 175, and 175 total items respectively); incremental sync is additionally available on 13 further /search endpoints including the transaction and journal-entry searches. The exact limitation: export covers only some resources. Work orders (1,534 rows in the evaluated account), bills, deposits, invoices, and inspections have neither an export path nor an updated-since filter — verified against every GET operation — so those datasets can only be kept in sync by re-paging the entire collection on every run. (Runs 1 and 2 graded this yes; resolved to partial — see "Three-run reconciliation".)
Webhook security and delivery reliability
Payload verification is present; delivery reliability is not documented. Rentvine issues a signing key: "This key is used to sign all HTTP payloads that we send to your webhook receivers. This is used to confirm that the data is being sent from Rentvine", and the key can be reset, which "will invalidate the old key". The exact limitations: no retry policy, delivery-failure behaviour, replay guidance, or consumer-side idempotency guidance is documented anywhere in first-party materials, and no payload format or signature-verification algorithm is published — so a consumer cannot implement verification from the documentation alone or know whether a missed delivery will be retried. [help.rentvine.com 16574284] Documentation-graded — battery step 8 not run: webhooks are UI-created with no registration endpoint, and no operator-controlled receiver was authorized.
Concurrency and conflict control
Neither optimistic concurrency nor documented conflict semantics exist. No ETag, If-Match, or version field appears anywhere in the specification, and none was present in the live response headers surveyed. No operation documents a 409 — the only documented status codes across all 205 operations are 200, 400, 401, 403, and 404. No concurrency limit or behaviour is described. Updates are partial-body POSTs that merge silently with no precondition mechanism (live-verified: POST /maintenance/materials/1 sent only description and the other fields were silently preserved), so two integrations updating the same lease will overwrite one another undetectably. The token field returned on list rows is documented as "a server-generated token (Unix timestamp) used as a cache-busting key", not as a concurrency control, and no operation accepts it.
Versioning and backward compatibility
There is no version contract at all. The base path https://{account}.rentvine.com/api/manager contains no version segment, no version header was present on any live response, the specification's info.version is "1.0.0" but is not expressed in any request, and no deprecation policy, breaking-change definition, or deprecation window is published — deprecat* occurs zero times. First-party terms take the opposite position explicitly: "Rentvine reserves the right to modify, enhance, suspend, or discontinue any API or related integration functionality at any time, with or without notice, and shall have no liability to Client or any third party for any resulting impact." [www.rentvine.com/terms]
Request traceability
A unique per-request identifier is present on essentially every response, but it is the CDN's rather than Rentvine's, and it is undocumented. Live 2026-09-02, responses carried X-Amz-Cf-Id (for example zj7Aco2GwHgSh6oP4Vf67rYYSrnJzVYHZ0nttyoFWElQBN8CnDVRFw==) and X-Amz-Cf-Pop. The exact limitations: no Rentvine-issued request or correlation identifier exists (x-request, request-id, and correlation occur zero times in the specification), X-Amz-Cf-Id is an Amazon CloudFront artifact that Rentvine does not document, and no first-party material establishes that it can be quoted to Rentvine support to trace a request. Notably the identifier is absent from exactly the case where it is most needed: the HTTP 500 empty-body response recorded under C2.3.
Service availability and status transparency
There is no public availability signal. https://status.rentvine.com resolves but is an application portal, not a status page: rendered in a browser 2026-09-02 it returned "Authorization Failure — You do not have access to this portal", with links to the owner, resident, vendor, and applicant portals. No status, uptime, incident-history, or trust page appears in www.rentvine.com/sitemap.xml. First-party terms disclaim the underlying commitment: "Rentvine does not guarantee any specific uptime or service level unless expressly set forth in a separate written service level agreement executed by the parties", and service interruptions "do not constitute a breach of this Agreement." No incident history and no uptime figures are published in any form.
Category 3 · Access Control
5 / 5Read-only credentials
An API key inherits a role, and role permissions separate view from edit, so a non-writing integration identity can be issued. The role documentation is explicit that disabling a modify toggle preserves read access: "If this toggle is off, they will still be able to view all of the deposits they will not be able to edit them." The specification reinforces this by naming a required write permission on each mutating operation. [help.rentvine.com 16574157; 16575275: "If you want to limit access to certain data, you can assign a restricted role."]
Scoped credentials
Scoping is fine-grained at the action level, not all-or-nothing. Roles span some fifteen permission categories (Administration, Accounting, Leasing, Properties, Contacts, Accounting Reports, Maintenance, Portfolios, Screening, Notifications, Portfolio Groups, Rentsign, System and others) with distinct action-level permission types including Manage, Modify, Void, Post/Charge, and Print, plus a specific "Manage Webhooks" permission. The specification names the exact permission each operation requires (for example POST /accounting/leases/{leaseID}/charges — "Requires the Add Charge permission"; /accounting/bills/{billID}/approve — "Requires ApproveBill"), and portfolio-level restriction is enforced on top ("Results are automatically restricted to the portfolios the authenticated account has access to"). Keys can further be associated "with a pod if your account uses pods", scoping a credential to a subset of portfolios. [help.rentvine.com 16574157, 16575275; operation descriptions]
Multiple keys
Multiple named keys coexist, each with its own role: "Click the API tab > New API Key … If you have created other Api keys before, you will see them listed on this page"; keys are created with a reference name (for example "Create New API Key with name 'tt-integration' and Role"). [help.rentvine.com 16573975; docs.rentvine.com "Obtaining API Keys"]
Rotation and revocation
Both are self-serve in the product, with no support ticket: "You can update the key name, change the assigned role, regenerate the secret, associate it with a pod if your account uses pods, or delete the key entirely." The secret is shown once at creation ("You will not be able to view the Secret again after closing this form"). [help.rentvine.com 16575275; docs.rentvine.com Authentication tag]
Test and production isolation
No sandbox or separate test environment is evidenced in any first-party source: the specification defines a single servers entry parameterised only by the customer's own account subdomain, and no first-party material references a test, sandbox, staging, or demo environment. With no test environment to isolate, the check does not apply and is excluded from the math. The consequence is captured where it belongs — under the evidence tier, which required the controlled live-data protocol for this run.
Category 4 · Docs & AI-Ready
2.5 / 5Complete self-serve reference
The reference is public, requires no login, and is unusually rich per endpoint, but it is materially incomplete and in places contradicts the API it documents. Strengths: a complete OpenAPI 3.1.0 document covering 205 operations across 143 paths, with authentication instructions and a worked curl example, per-endpoint summaries, "Use Cases", "Business Rules", "Available Includes", "Related Endpoints", generated curl samples, named permission requirements, and response examples on the large majority of operations. The exact limitations: (1) it omits working endpoints — GET /accounting/bank-accounts returned 200 with real trust-account data but appears nowhere in the specification, and bank accounts are a critical object; (2) it omits webhooks entirely, which are documented only in the customer help centre, so a developer reading the API reference would conclude Rentvine has no events; (3) its own "Related Endpoints" sections cite 26 distinct endpoints that do not exist, including GET /bills/{billID} (cited 7 times), POST /bills (5), DELETE /bills/{billID} (4), PUT /bills/{billID} (3), and GET /accounting/ledgers/{ledgerID} (2); (4) two declared paths carry no operations because their $refs point to unpublished files; (5) there is no overview material on errors, rate limits, versioning, or pagination semantics — info.description is absent and only 6 of 20 tags carry any prose, with the core tags (Properties, Units, Screening, Custom Fields, all four Export tags) empty; and (6) documented behaviour is contradicted live — GET /accounting/ledgers is documented as "supplying neither returns an empty result set" but returned HTTP 400 "Search Failed", page_size_25 declares default 25 while its own description says 15, and declared field types contradict the live payloads as detailed in C2.2.
Reliable machine-consumable integration path
Two first-party mechanisms exist; neither is complete and maintained to the standard this check requires. The OpenAPI 3.1.0 specification is the strongest available path — it is published, downloadable from the docs page, and covers all 205 operations — but it requires substantial manual correction before code generation: 324 type arrays contain a literal JSON null instead of the string "null" (invalid JSON Schema, including inside the POST /accounting/leases/{leaseID}/payments request body on bankAccountID and prepaymentAccountID); three distinct invalid type strings appear across five occurrences (date-time, date, search) on the incremental-sync and search parameters; seven array schemas declare no items; four $refs dangle to unpublished external YAML files; some properties declare no type at all; and declared integer types contradict live string responses across the core object model. It is also served only inside a 7.4 MB Redoc HTML page — docs.rentvine.com/openapi.json returns 403 — so there is no stable machine-fetchable URL. Rentvine additionally ships a first-party MCP server with "90+ governed tools" spanning "Portfolios Properties Units Leases Residents Owners Vendors Work Orders Inspections", included for every customer and running "under your Rentvine roles and permissions" — but it is not generally available ("The MCP is in beta now and going live later this year") and is "Read-only by design", so it is not an operations-capable path to the write operations that make this API useful. No official SDK is evidenced in any first-party source.
AI-readable documentation
A first-party AI-oriented resource exists but does not represent the API. www.rentvine.com/llms.txt is present, well-formed, and current ("_Last updated: 2026-06-10_", 8,675 bytes), but it is a product and marketing corpus — about, value proposition, audience, capabilities, core pages, FAQ — whose entire API content is three bullet lines, one link, and one FAQ pair, with no endpoint, parameter, schema, authentication, or error information. llms-full.txt returns HTTP 404. The documentation host serves no AI-oriented resource at all: docs.rentvine.com/llms.txt, /llms-full.txt, /openapi.json, /openapi.yaml, and /sitemap.xml all return HTTP 403, and there is no per-endpoint Markdown or downloadable documentation corpus. The API's only machine-retrievable representation is the OpenAPI JSON embedded in the single 7.4 MB HTML bundle — comprehensive in coverage, but carrying the schema defects recorded in C4.2 and requiring extraction from page state rather than retrieval as documentation.
Kept current
Currency information exists and the underlying materials are actively maintained, but there is no reliable signal for API changes specifically. Rentvine publishes 57 release-note entries, and the API-relevant help-centre articles are demonstrably fresh (the Open API guide and webhooks article updated 2026-08-26; User Roles 2026-08-31; an integration article 2026-09-01). Webhooks were announced through a dated release note in November 2024, establishing that developer-facing changes do sometimes appear there. The exact limitations: none of the ten most recent release notes mentions the API, endpoints, or developer-facing changes; the release-note index shows no dates; there is no API changelog, no specification version history, and no deprecation notices; the specification contains no deprecated markers; and the terms clause permitting API changes "at any time, with or without notice" (C2.10) removes any commitment to notify at all.
Category 5 · Access & Cost
15 / 15Self-serve API key
An entitled operator creates credentials unaided, in the product, with no sales call, support ticket, or approval step. The documented sequence is Settings → Users, Roles and API → API tab → New API Key → name and role → copy the access key and secret. [docs.rentvine.com "Obtaining API Keys"; help.rentvine.com 16575275: "Generate API keys directly inside Rentvine"; independently corroborated by integration guides instructing customers to self-issue keys. Live-verified 2026-09-02: a self-issued key authenticated successfully against the production account, and a bogus credential was correctly rejected with HTTP 401.]
Not commercially gated
API access is included, not tiered or sold as an add-on. Rentvine sells a single plan — "Universal pricing. One simple plan." — at "as low as $1.50 per unit" with "All features included", listing "Fully Open API & Integrations" among them and stating "Other platforms charge extra for core functionality … Rentvine keeps it simple: one plan, every feature, full support." The MCP server is likewise "Not an add-on. Included for every Rentvine customer as part of your plan." No premium tier, add-on fee, integration fee, or per-call charge for API access is evidenced in any first-party source. [www.rentvine.com/pricing; /open-api; /features/mcp]
What works
- One plan with the API included, and a self-serve key in about two minutes
- Action-level key permissions, including view-only, restrictable to part of your portfolio
- The full trust ledger is reachable, alongside properties, units, leases, tenants, owners and work orders
- A public OpenAPI 3.1 spec with no login, naming the permission each operation requires
- Pagination that works, with eight populated headers and live-verified page traversal
- Four export endpoints with an updated-since filter, live-verified
- A first-party MCP server included in the plan, though still in beta and read-only
What to watch
- The API can post a charge or payment to a lease but cannot void or reverse one
- No journal-entry posting and no chart-of-accounts writes, so corrections stay manual
- No idempotency anywhere, so a retried charge can post twice to a real trust ledger
- Numbers and booleans return as text, and the published spec declares some of them numbers
- Five error formats, including one unparseable and one empty server error
- No published rate limit and no rate-limit headers of any kind
- No concurrency control, so two tools can silently overwrite each other on the same lease
- No API version contract, and the terms allow changes at any time without notice
- No status page: status.rentvine.com is an application portal, not an availability signal
- Webhooks cover four object types and nothing on the money side
The bottom line for a property manager
Rentvine's API is genuinely open in the way that matters most: it is included in the one plan at no extra cost, you can issue your own key in two minutes without a sales call, and the permission controls are excellent, with a separate least-privilege key for every tool or AI agent, revocable in seconds. Its functional reach is real too. Properties, units, leases, tenants, owners, work orders, bills, screening and the full trust ledger are all reachable, and most of it is changeable. What you can build today is substantial: nightly portfolio syncs, custom dashboards and reporting, renewal and delinquency tracking, maintenance automation, and AI assistants that read your live data. What you cannot build safely today is anything that posts money unattended. The API will post a charge or payment to a lease but offers no way to void or reverse one, no protection against a retried request posting twice, and no journal-entry posting for corrections. That work belongs in the web application with a human. The score is held down not by what the API can do but by the guarantees it does not make: text-typed numbers that contradict the published schema, five error formats including two that cannot be parsed, no published rate limit, no way to stop two tools overwriting each other, no export or change filter for work orders and bills, no version contract, and no status page. Integrations here need more babysitting than the feature list suggests. Rentvine is a property-management system of record with documented trust-accounting workflows, and it is not a bank: it accounts for money held in trust accounts you open in your own name at your own institution, so you still need that bank, a payment processor, and the web application for corrections the API cannot make. A D+ is a grade for API engineering discipline, not a verdict on the product. On openness and cost of entry, where most competitors fail outright, Rentvine scores full marks.
Check it yourself.
Both files behind this page, in full.
Rentvine’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 Rentvine 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.