Why accounting wants Buildium in ChatGPT read-only
Jake Morgan is the controller for a property management company. At month end he wants three answers fast. Which ownership accounts are more than 90 days behind? What cleared the operating account last week? Does the general ledger agree with the budget for the Elm Street association? Buildium in ChatGPT can answer all three. Nobody wants the same chat able to pay a bill or finalize a reconciliation.
MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. No MCP server is documented in Buildium's developer guide, "Open API, powered by Buildium" (developer.buildium.com, checked October 2026). So ChatGPT reaches the books through a connector that calls the Open API. Elaichi's buildium connector is that connector. It carries 337 tools, and 154 of them create, update, delete or run a request. Among them are create_a_buildium_bill_payment, create_a_buildium_bankaccount_withdrawal and create_a_buildium_reconciliation_finalizerequest.
Read-only has two layers here, and each does a different job. The Buildium API key limits what any call can do. The Elaichi rule limits what each role is offered, in every client.
Start with a read-only Buildium API key
The first layer is the key, because Buildium checks it on every call. Buildium keys are account-level, with a client ID and a secret. Creating one takes an administrator role, under Settings, then Developer Tools, then Create API Key (developer.buildium.com, checked October 2026). The creator ticks which pieces of Buildium data the key may reach. Buildium's guide adds that a key can be restricted to particular entities or to read-only access, meaning GET resources only.
Make the accounting key read-only and tick only the accounting data. Buildium's reference shows why it matters. Paying several bills with one check needs Accounting, Bills and Accounting, Bank Accounts, each with View and Edit. A withdrawal needs Bank Accounts with View and Edit. A key without Edit gets a 403 Forbidden on those calls. The Open API itself needs a Premium Subscription, which Buildium's pricing page lists with "Full AI and Automations suite, plus Open API" (buildium.com, checked October 2026).
Give accounting its own key and its own connection. The operations team may need a key that creates work orders. If both teams shared that key, accounting's reach would be the operations key's reach. Buildium shows a secret only once, so paste it straight into Elaichi when you connect.
Why the key alone is not the whole answer
A read-only key stops the write at Buildium. It does not stop the model from being offered the write, trying it and getting an error. It also does nothing for a person who can reach a second, broader Buildium connection. Elaichi's restrictions cover both gaps.
A restriction is a rule naming which connectors and which individual tools a role or a member may reach. It is checked at every place a member can reach a connector or tool, including listing, connecting, advertising, executing, the final outbound-request check and opening a stored tool file. Restrictions bind the person calling, whatever connection or client the call comes through. So an accountant who is also shared the operations connection still cannot run its payment tools. A restricted tool is withheld from the tool list and cannot be called.
Write one allow rule that names only the reads
One allow rule on the accounting role, naming the Buildium reads the team uses, gives you Buildium read-only in Elaichi. In Elaichi, the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything. Once the role holds an allow rule, every connector and tool that no allow rule names is denied for it. Every Buildium create, update and delete tool falls away without a rule of its own.
Name these reads, and add others the team asks for:
| Question | Buildium read tool |
|---|---|
| Who is behind, and by how much | list_all_buildium_ownershipaccounts_outstandingbalances |
| What cleared the bank | list_all_buildium_bankaccount_transactions |
| Where each reconciliation stands | list_all_buildium_bankaccount_reconciliations |
| What the ledger says | list_all_buildium_generalledgers |
| What was paid on a bill | list_all_buildium_bill_payments |
| Budget against actual | list_all_buildium_budgets |
| What a vendor was paid | list_all_buildium_vendor_transactions |
The rule is the role's whole allowlist, not a Buildium filter. Name every other app the accounting team uses, as whole connectors, in this rule or a second allow rule on the same role. Otherwise the team loses those apps too.
Three more points to get right:
- Targets are a role or one member. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. Accounting needs its own role, and each member holds exactly one. Designing roles for AI agents covers how to shape it.
- Do not name the Buildium connector whole and some of its tools in one rule. Elaichi refuses that overlap on a new rule, because the whole-connector entry would admit everything.
- Allows match the operation, not the name. An allow rule matches the operation pinned when the rule was saved. A new Buildium write tool added to the connector later is denied for the role with no rule edit. Why blocks match names and allows do not explains the difference.
A restriction change takes effect within about two minutes. If a read still looks restricted right after you save, wait out that window before you debug.
What the accounting reads need from the person asking
Several Buildium reads need ids, so tell the team to include them. list_all_buildium_bankaccount_transactions needs a bank account id, a start date and an end date. list_all_buildium_generalledgers needs an accounting basis, the GL account ids and a date range. list_all_buildium_vendor_transactions needs a vendor id and a range of at most 365 days.
"Show me what cleared bank account 1042 from October 1 to October 9" works on the first try. "What cleared last week?" makes the model ask, or guess. The outstanding balances read needs no id. It returns, per association ownership account, a total balance and balances aged 0 to 30, 31 to 60, 61 to 90 and over 90 days.
Results are capped before they leave Elaichi: 32,000 characters per string and 200 items per list, with the cut flagged. Narrow the date range rather than asking again. Buildium also limits a client to 10 concurrent requests per second, and the whole team shares one key's limit (developer.buildium.com, checked October 2026).
Publishing the Elaichi app in ChatGPT
Every organization uses one address: POST https://api.elaichi.ai/mcp. To ChatGPT, Elaichi is one app for the whole organization. On ChatGPT Enterprise and Edu, the Publish dialog's Configure Actions step picks which actions the app may use, and Configure Access picks the groups (help.openai.com, checked October 2026). After approval, ChatGPT works from a frozen snapshot of the app's tools until an admin refreshes it. The full setup is in connecting Elaichi to ChatGPT.
Do not lean on a read-only setting in ChatGPT. In Elaichi, connected tools are never listed one by one, however few there are. Every connected Buildium tool runs through a few Elaichi tools, such as execute_tool, and none of those is marked read-only. A read-actions setting on the Elaichi app cannot tell a balance read from a bill payment. The same holds on Elaichi's consent screen: "Run your connected tools" runs writes as well as reads. The allow rule is the control.
Check it from an accounting account
Sign in from a test account on the accounting role. Ask for the aged balances at one association, and the read should run. Then search for "payment", "withdrawal" and "finalize". The read list_all_buildium_bill_payments comes back runnable. The create tools come back by name, flagged restricted, with no schema.
Then read the audit trail. Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none). Each entry records the tool, the connection reached, the outcome and the client, plus the one path argument that names the object, as the target id, and nothing else about the arguments. An outside auditor can read it from a free Auditor seat, which holds view permissions only and cannot run a tool. What an AI audit log must capture lists what to look for.
When someone needs a write later, they file an access request. An admin approves it in the console, under Governance, then Access requests. The grant lifts that one tool for that one person. The rule stays as written, and nobody else changes. A key restricted to read-only still refuses the write at Buildium, so that person needs a connection with a broader key as well.
When the Buildium app is enough on its own
If the controller works inside Buildium and asks only Buildium questions, the app's own reports and AI may be enough. Buildium's pricing page lists Lumina AI features, including AI Bill Scan and Lumina AI Workforce (buildium.com, checked October 2026). One analyst with a read-only key and a script also needs nothing more.
Elaichi earns its place when several people ask, from ChatGPT, Claude or Cursor, about Buildium and the other systems finance runs. One endpoint, one allow rule per role and one audit trail cover all of it. The same shape on another ledger is in QuickBooks read-only for a finance team. The operations side of Buildium, with work order creation allowed, is in Buildium in Claude for a property operations team. Read what an MCP control plane is for the idea behind it, or browse the 600+ connectors.
