Rentvine API: the filters it ignores, and why that matters once AI reads your books

Key takeaways

• The Rentvine API drops any query parameter it does not recognise and answers HTTP 200 with the unfiltered result. Ask its transaction search for one lease with `leaseIDs[]`, a filter the lease export accepts and the search does not, and you get exactly what you get by asking for nothing. On September 30 the first 400 of those rows came from 177 different properties.
• Every filter listed in Rentvine's published reference did what it said in our tests. Every one that failed was a plausible guess: `limit` for `pageSize`, `startDate` for `datePostedMin`, `accountIDs[]` for `ledgerIDs[]`. An AI assistant writing its own calls guesses in exactly that way.
• Rentvine's MCP keeps financials read-only, which protects the books from a bad write. A bad read is a separate problem, so everything we build on Rentvine uses only documented parameters and checks each filtered result against its filter before a number reaches an owner.

What we ran it on

The Rentvine API is the most open ledger API we work with in property management. Any customer can create a key in the account's own settings, scoped to a role, and the reference is public at docs.rentvine.com. Buildium, by comparison, keeps its API on the Premium plan, as we covered in our Buildium automation guide.

The operation we work inside, a Toronto property management and brokerage operation, keeps its books in Rentvine. Since the end of June we have done a good share of its ledger work through that API: charges and credits, transfers between ledgers, new owners and leases, move-out close-outs, owner statement checks. When Rentvine announced its MCP in May, its chief executive called the API the best way to deploy AI in property management. For writes we would mostly agree.

Reads are where it bites. Everything below was re-run for this post on September 30, 2026, read only, with every record reduced to a count. Anything older carries its own date.

What it does with a parameter it doesn't know

| Request | In the reference? | What came back |

|---|---|---|

| Transactions for one property, `propertyIDs[]` | Yes | 90 rows, all from that property |

| Transactions for two days, `datePostedMin` and `datePostedMax` | Yes | Only those two days |

| Transactions for one lease, `leaseIDs[]` | No, only on the lease export | The same first 100 as no filter, row for row |

| Transactions for one unit, `unitIDs[]` | No | The same again |

| Ledger entries for two days, as `startDate`, `datePostedFrom` or `dateFrom` | No | The unfiltered first page, dated October 1 to November 1 |

| Ledger entries for one account, `accountIDs[]` | No, it's `ledgerIDs[]` | The unfiltered first page |

| Five properties, `limit=5` | No, it's `pageSize` | 15, the default page |

| Only inactive staff users, `isActive=0` | No, the user list isn't documented | The active users |

Every row came back as HTTP 200 with a normal list in the body. Nothing in the response says a filter was dropped.

Most of our own mistakes on this API came from carrying a name across from somewhere it worked. `leaseIDs[]` filters the lease export, so it looks safe on the transaction search. `limit` is what most APIs call it. One endpoint, the list of undeposited receipts, documents no paging parameters at all, and in early September a loop that sent it `page` counted the same rows about 80 times before anyone noticed the total was absurd.

That is usually how these turn up, as a total that is obviously wrong. Someone running a report who gets 177 properties back for one lease knows something broke. An AI assistant asked what a tenant has paid since June gets a list of real transactions in the right format, sums it, and replies with a confident figure made of other people's rent.

Our own bridge made the same mistake, which is how we know how easy it is to make. It is the connection that lets Claude work this account, with named tools plus a generic call for anything else. Until September 30 its list tools passed `limit`, and so did the examples it showed the assistant. They send `pageSize` now.

Rentvine's MCP, and where the risk sits

Rentvine's own MCP has been in closed beta since at least July, when a sales engineer demonstrated it on a live account. Connected to Claude, it found duplicate work orders, deleted eight of the nine it found on one property, and set up an hourly job assigning a plumber to any pending plumbing work order there with no vendor. The setup page says financials are read-only through it and that Claude and ChatGPT ask you to confirm before creating or changing anything. Rentvine says it goes live for every customer later this year, included in every plan.

Read-only financials are the right call, and they answer the obvious fear, an AI posting a charge it shouldn't. They don't touch a read that looks filtered and isn't. We have not had the beta, so we can't say whether its tools send only the documented parameters. A named tool built by Rentvine probably does. The exposure is highest wherever an assistant composes its own requests, which is what Rentvine invites teams to do when it says they can build custom agents on "the same connection and our open API".

A filter that works can still mislead

Even a correct pull needs care, because of how Rentvine records money. Every ledger entry carries two flags, `isCash` and `isAccrual`. A rent charge posts accrual entries. The tenant's payment posts a cash set and an accrual set. Add up rent income across the entries without choosing a basis and every paid month counts twice, once when it was charged and once when it was paid. The reference lists both flags as filters on the entries search, and they work; use one.

The property filter has a gap of its own. A pull scoped to a property leaves out whatever is booked at the portfolio level, and owner distributions are booked there, so a property's money in and out comes back without the owner's payouts. We found that one in August.

The reference is right about parameters and short on endpoints

The public reference lists 143 paths and 205 operations today, with no webhook path and no audit path. We have used seven ledger writes on the live account that it doesn't list: posting a lease credit, a transfer between ledgers, a recurring credit, reallocating a payment, reallocating a credit, voiding a charge and voiding a payment.

The audit log is the most useful thing it leaves out. The web app's timeline reads it from `logs/{objectTypeID}/{objectID}`, and `logs/0/0` is the whole account, newest first, with the user behind every entry and the old and new value of every field changed. We found it in August by reading the web app's own code, after the obvious guesses (`audits`, `audit-logs`, `activity`, `history`) had all returned 404, as they still did on September 30. Being undocumented, it ignores a `userID` filter like the rest, so you sort the feed yourself. Once an assistant is writing to the account, that feed is where you check what it did; the work order timeline in Rentvine's demo, where the MCP's actions show up, is one view of it.

Some jobs the API can't do at all. Paying a bill and managing portal invitations are web app only. Updates drop fields they don't accept the way searches drop parameters: moving a property to another portfolio, or adding an email address to an existing owner, returns 200 and changes nothing (the email case last confirmed September 24). And with no webhooks, integrations poll. LeadSimple's syncs work orders every five minutes, and our LeadSimple API field notes measure what that means in practice.

What we check before anything reads Rentvine

• Parameters come from the reference and nowhere else. A name that works on one endpoint gets checked again on the next.
• Every filtered read is checked against its filter. Ask for one lease and every row has to belong to that lease, or the job stops and says so.
• A total is reconciled against a balance Rentvine computes itself before it reaches an owner, a tenant or a report.
• Pages are requested with `pageSize`, counted until they run out, and deduplicated on the transaction ID.
• Money is summed on one basis, cash or accrual, and the report says which.
• Writes are off by default and armed only for the job that needs them, and every write is read back afterwards, because on this API a 200 tells you the request arrived and not much more.

None of this is a reason to avoid Rentvine. It is the platform we would pick for the work we do, and the open API is most of the reason. If your operation runs on it and you are about to connect an assistant, our property management page covers how we scope that work, and the AI readiness audit is where we would start.