# Buildium in Claude for a property operations team

> Buildium in Claude lets a property team check units, leases and work orders in chat. Scope the API key, then keep resident email and money writes off.

**TL;DR** Buildium in Claude runs through a connector that calls the Buildium Open API with one account-level API key. In Elaichi, the property operations role gets an allow rule naming the Buildium reads it uses plus work order and resident request creation, and block rules keep resident email, payments, refunds and deletes out of reach. The key itself is the outer wall: Buildium lets an admin limit what data a key can reach.

## Why a property team wants Buildium in Claude

Emily Carter runs operations for a portfolio of rentals and two associations. Her Monday questions are always the same. Which units are listed and at what rent? Which work orders are open and past due? Has the tenant in 4B filed proof of renters insurance? Each answer sits in Buildium, behind a different screen. Buildium in Claude puts those lookups in one chat, next to the email thread and the vendor quote she is already reading.

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](https://developer.buildium.com/), checked October 2026). Buildium's own AI features, which its pricing page lists as Lumina AI, come with Buildium's plans. So the path from Claude to a live Buildium account is a connector that calls the Open API.

[Elaichi's `buildium` connector](/connectors/buildium/) is that connector. It signs in with one Buildium API key and carries 337 tools: 183 reads, 73 creates, 52 updates, 10 deletes and 19 file and image requests. An operations lead needs a small part of that. The rest of this playbook is about which part, and how to keep the others away from the model.

## What the Buildium API key decides before Elaichi does

The Buildium API key is the outer wall, because every call through the connection uses it. Build it narrow first. Buildium's Open API needs a Premium Subscription, and turning it on takes an administrator role with access to Application settings ([developer.buildium.com](https://developer.buildium.com/), checked October 2026). The toggle sits under Settings, then Application settings, then Api settings.

Keys are account-level and have two parts, a client ID and a secret. An administrator creates one under Settings, then Developer Tools, then Create API Key. The next screen asks which pieces of Buildium data the key may reach, as a set of checkboxes. Buildium's guide is blunt about the default risk: based on their permissions, keys "could have full access to your account's Buildium data". It also says a key can be restricted to particular entities or to read-only access.

Buildium's API reference names the permission each endpoint needs, and that tells you what to tick. Creating a work order needs Maintenance, Work Orders with View and Edit. Sending an email needs Communication, Emails with View and Edit. A key without the email permission gets a 403 Forbidden on that call, whatever the model asks for. The secret is shown once, at creation. Paste it straight into Elaichi and keep no other copy.

Give the operations connection its own key. If finance later needs Buildium too, it gets a second key and a second connection, so neither team's reach depends on the other's checkboxes.

## Which Buildium tools an operations lead actually needs

Most of what Emily asks is a read, and a few reads span the whole account. `list_all_buildium_workorders` and `list_all_buildium_tasks_residentrequests` filter by status, priority, unit, vendor and due date. `list_all_buildium_rentals_units` and `list_all_buildium_rentals` cover the portfolio. `list_all_buildium_applicants` covers who has applied. `list_all_buildium_communications_phonelogs` covers who called.

Lease reads are narrower. `list_all_buildium_lease_rents`, `list_all_buildium_lease_rentersinsurances` and `get_single_buildium_lease_renewal_by_id` each take one lease id, and no read tool returns the list of leases itself. The model needs the lease from the person asking or from another record. `list_all_buildium_unit_listings` likewise returns the active listing for one unit at a time.

| Kind | Example tools | For the operations role |
|---|---|---|
| Portfolio and task reads | `list_all_buildium_workorders`, `list_all_buildium_rentals_units`, `list_all_buildium_applicants` | Allow |
| Lease reads by lease id | `list_all_buildium_lease_rentersinsurances`, `list_all_buildium_lease_rents` | Allow |
| Task creation | `create_a_buildium_workorder`, `create_a_buildium_tasks_residentrequest` | Allow |
| Resident email | `create_a_buildium_communications_email` | Restrict |
| Money movement | `create_a_buildium_bill_payment`, `create_a_buildium_bankaccount_withdrawal`, `create_a_buildium_lease_refund` | Restrict |
| Deletes | `delete_a_buildium_unit_listing_by_id`, `delete_a_buildium_lease_moveout_by_id` | Restrict |

The email tool sends a templated message to one or more current tenants. That is an outbound message under the company's name, and a wrong merge field reaches residents. Deleting a unit listing takes it off the Buildium public website at once and off syndicated sites within 24 to 48 hours, per the tool's own description.

Updates need their own caution. `update_a_buildium_workorder_by_id` replaces the record: any field left out is cleared to empty or null. Buildium's reference says the same of its update endpoints and recommends a GET first. A model that sends only the new due date can wipe the vendor and the line items. Keep updates in the Buildium app and let Claude create.

## Writing the rule on the operations role

One allow rule on the operations role gives Emily's team the reads and the two creates, and nothing else from Buildium. A restriction is a rule naming which connectors and which individual tools a role or a member may reach. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. So the team needs its own role, and each member holds exactly one.

Name the read tools the team uses, then `create_a_buildium_workorder` and `create_a_buildium_tasks_residentrequest`. The same rule, or a second allow rule on the role, must also name every other app the team uses, as whole connectors. 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 a role holds an allow rule, every connector and tool no allow rule names is denied for it. A Zendesk or Slack connector left off the list is lost to the role.

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 every tool. Allow rules match the operation pinned at save time, and block rules match the name or the operation. [Why blocks match names and allows do not](/blog/block-matches-name-allow-matches-operation/) covers the reason.

Then add block rules on `create_a_buildium_communications_email`, the payment, withdrawal and refund tools, and the ten delete tools. Within a layer, a block always beats an allow. So if someone later widens the allow rule to all of Buildium, those tools stay restricted. A restriction change takes effect within about two minutes. [Per-tool versus per-app restrictions](/blog/per-tool-vs-per-app-restrictions/) compares the two shapes.

## Connect once, share it, and point Claude at it

An operations admin connects the buildium connector once with the key's client ID and secret, then shares that connection with the team at `use`. A shared connection runs on its owner's credential. Every member's call reaches Buildium with the same key, and Elaichi records which member made each call. Those credentials sit in a separate credential service, encrypted at rest.

Pick an owner who will stay. When an owner leaves, Elaichi's offboarding lists every connection they own, and an admin transfers it to another member. A transfer leaves every share as it was. [Offboarding when the agent holds access](/blog/offboarding-when-the-agent-holds-access/) covers the rest of that checklist.

Every organization uses one address: `POST https://api.elaichi.ai/mcp`. On Claude Team and Enterprise, an Owner adds it under Organization settings, then Connectors, then Add, then Custom, then Web. Members then connect it under Customize, then Connectors ([support.claude.com](https://support.claude.com/en/articles/11175166), checked October 2026). Each member signs in with their own OAuth grant, the sign-in that ties their Elaichi identity to that client. The full setup is in [connecting Elaichi to Claude](/blog/connect-elaichi-to-claude/).

In Elaichi, connected tools are never listed one by one, however few there are. Claude reaches Buildium through `search_tools` and `execute_tool`, so a Claude permission set on `execute_tool` covers every connected app at once. On Elaichi's consent screen, "Run your connected tools" runs writes as well as reads. Only a delete also needs "Delete data and remove access", which is never pre-ticked. Neither box is the control here. The role's rules are.

## Check it from an operations account before rollout

Sign in from a test account on the operations role and ask Claude for open work orders at one property. The read should run. Then search for "email" and "refund". Both should come back by name, flagged restricted, with no schema, and neither can be called. Buildium includes one sandbox account with Premium, and a key works only in the environment that created it. Connect a sandbox key as a second connection and create a test work order there.

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. A lease id in a read's path is recorded; the body of a create is not. [What an AI audit log must capture](/blog/what-an-ai-audit-log-must-capture/) lists what to check in those rows.

Mind the rate limits on both sides. Buildium allows 10 concurrent requests per second per client and suggests exponential backoff after a 429 ([developer.buildium.com](https://developer.buildium.com/), checked October 2026). Elaichi limits a token to 120 MCP requests a minute. A shared key means the whole team shares Buildium's limit.

When someone needs a restricted tool 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, and the role is not edited.

## When Buildium's own AI is the better fit

If the team works inside Buildium all day, Buildium's own AI may cover some of it. Buildium's pricing page lists Lumina AI features: Buildium Assistant (Help Only), Write with Lumina, Lumina AI Workforce and AI Bill Scan ([buildium.com](https://www.buildium.com/pricing/), checked October 2026). Buildium's blog says its Maintenance Workforce agent can "summarize task threads and close completed work orders on their own" ([buildium.com](https://www.buildium.com/blog/level-up-automation-and-ai-in-property-management/), checked October 2026). That needs no second vendor and no API key.

Elaichi earns its place when the question crosses apps. Emily's work order lives in Buildium, the vendor's quote is in email and the resident's complaint is in the help desk. With Elaichi, one endpoint serves Claude, ChatGPT and Cursor alike. One set of rules says what each role may reach, and one audit trail shows who asked what. The same pattern, held to reads, is in [Buildium for accounting in ChatGPT](/blog/finance-team-chatgpt-buildium-read-only/). If one person only wants to test a few queries, [you may not need a control plane yet](/blog/when-you-dont-need-an-mcp-gateway/). Browse the [600+ connectors](/connectors/) for the rest of the stack.

## FAQ

### Does Buildium have its own MCP server?

No MCP server is documented in Buildium's developer guide, "Open API, powered by Buildium" (checked October 2026). Buildium's own AI features, listed on its pricing page as Lumina AI, come with Buildium's own plans. Reaching Buildium from Claude, ChatGPT or another MCP client takes a connector that calls the Buildium Open API, such as Elaichi's buildium connector.

### Can a Buildium API key be limited to some data or to read-only access?

Yes. When a Buildium administrator creates an API key, they tick which pieces of Buildium data the key may reach. Buildium's developer guide also says a key can be restricted to particular Buildium entities or to read-only access, meaning GET requests only (checked October 2026). The guide warns that, depending on their permissions, keys could have full access to an account's data.

### Can Claude send emails to residents through Buildium?

Through a connector, yes. Buildium's Send an email endpoint sends a templated email to one or more current tenants, and Elaichi's buildium connector exposes it as create_a_buildium_communications_email. In Elaichi, a block rule on that tool for the operations role keeps it out of reach. The tool is withheld from the client, and search names it only as restricted.

### Why should an AI client not update Buildium work orders?

Buildium's update endpoints replace the whole record. Any field left out of an update request is set to an empty string or null, and Buildium recommends reading the record first. A model that sends only the field it wanted to change can clear the rest. Creating a work order is safer to hand to an AI client than updating one.

### How quickly does a new Buildium restriction take effect in Elaichi?

A restriction change in Elaichi takes effect within about two minutes, so test a new rule after that window rather than straight away. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change.

## Read next

- [Buildium in ChatGPT, read-only for accounting](/blog/finance-team-chatgpt-buildium-read-only/) — Buildium in ChatGPT for a property accountant: a read-only Buildium API key, plus one Elaichi allow rule that names only the accounting reads.
- [Zendesk for support agents, minus bulk deletes](/blog/support-team-claude-zendesk-tickets/) — Zendesk for support agents in Claude: let them read and update tickets, block deletes and bulk sends, and give the lead one exception.
- [Jamf in Claude on a read-only API role](/blog/it-team-claude-jamf-devices/) — Jamf in Claude lets a help desk check a Mac's inventory mid-ticket. Build a read-only Jamf API role, then narrow it per person with Elaichi restrictions.