Shared keys get copied and lockbox codes get forgotten, so a plumber from last spring can still let himself in. Rentari issues a vendor a smart-lock PIN the moment they accept the job, then clears it from the lock when the ticket is marked complete. Connected leak, freeze, and smoke sensors open their own maintenance tickets, and an AI Doorman watches the access log for entry patterns that look off.
The problem with keys, lockboxes, and codes you forget
Self-managing a few units means handing out access constantly. A plumber needs to get in Tuesday afternoon. A cleaner comes between tenants. An HVAC tech swings by for a seasonal check. The usual tools for this are a hidden key, a lockbox with a four-digit code, or a smart-lock PIN you type in by hand and mean to delete later.
Each one leaks. A hidden key gets copied. A lockbox code gets texted around a vendor's crew and never changes. A smart-lock PIN you set manually sits there active for months because deleting it is one more thing on a list you never finish. The result is the same: people you no longer work with can still open a door, and you have no clean record of who came and went.
Rentari closes that gap by tying access to the job, not to a person you have to remember to revoke. The access exists for the work, then it ends.
A vendor PIN that issues on dispatch and revokes on completion
When you assign a maintenance ticket to a vendor and the vendor accepts the dispatch, Rentari asks your connected smart lock to create a time-boxed access code for that visit. The code is scoped to the ticket and carries an arrival window. The vendor sees it on their ticket detail page, and the tenant sees it on their maintenance view, so nobody has to coordinate a key handoff.
When the ticket is marked complete, the same flow runs in reverse. Rentari tells the lock to delete that access code before the completion summary even goes out, and clears the cached code from the ticket so the vendor and tenant views stop showing it. There is no separate cleanup step for you to remember, because the revoke is wired into the completion of the work itself.
No shared keys. No standing lockbox code. No PIN that outlives the job by six months. The access opens when the vendor takes the work and closes when the work is done.
The key takeaway: Access in Rentari is tied to the job. A vendor's smart-lock PIN is created when they accept the dispatch and deleted from the lock when the ticket is completed, so the door is open for the visit and closed after. Every entry lands in the log for that unit, and an AI Doorman flags access patterns that look off. You stay in control, because Rentari proposes and you approve.
Sensors that open their own ticket, then stop
A small drip behind a wall is cheap on Tuesday and a flooded unit by Friday. The whole point of a leak, freeze, or smoke sensor is to catch the thing while it is still small, but a sensor that only buzzes a phone at 2 a.m. is easy to sleep through.
When a connected sensor reports a critical alert, Rentari opens a high-priority maintenance ticket on its own. The ticket arrives pre-filled with the issue, the severity, and the location, and both you and the tenant are notified the moment it fires. The event is written to the entry log and the audit trail so there is a record of when the sensor caught it and what happened next.
Here is the honest boundary, by design. The sensor opens a ticket. It does not take an irreversible physical action. Rentari does not slam a valve shut or cut power on a reading, because a false positive that does that is its own emergency. The sensor catches the moisture and writes the work order, then you and your plumber decide what happens next. That is the same principle that runs through the whole product: AI proposes, you approve, and nothing irreversible happens behind your back.
An AI Doorman that reads the access log
A log only helps if someone reads it, and nobody reads an access log every morning. Rentari's AI Doorman does. It looks at the current state of your locks and active codes and surfaces the people-level patterns a human would miss: a vendor PIN still active well past its work window, a one-time guest code that went stale, a former tenant whose code somehow never got cleared.
When the Doorman flags something, it hands you a card with the issue and a button. If a specific code should go, the card offers to revoke that exact PIN. Nothing is auto-executed. The Doorman points at the anomaly and you make the call, which is the right division of labor for something that controls a physical door. It also stays grounded: it only flags an anomaly it can tie to a specific code and its window or role, rather than inventing one.
The honest requirements
These are hardware features, so they need hardware. The smart-lock and sensor capabilities run on Seam, which connects to supported locks and devices (August, Schlage, Yale, and others in Seam's network). You connect your lock through an onboarding flow, and from then on Rentari can issue codes, read the device state, and receive the lock's events.
Until you connect a device, these screens show an empty onboarding state rather than fake data, and a leak ticket cannot open for a sensor that does not exist. We would rather be plain about that than imply your existing dumb deadbolt is suddenly a smart lock. If you do not run any connected hardware, the rest of Rentari (screening, leases, accounting, the AI co-pilot) works exactly the same, and this is the piece you switch on when you add devices.
How this compares
Plenty of platforms integrate with smart locks or third-party IoT in some form. What we did not find, reading each vendor's public documentation as of June 2026, was the specific loop in this post: a vendor PIN that issues itself on dispatch and revokes itself on completion, a native leak, freeze, or smoke sensor that opens its own maintenance ticket, and an AI pass over the access log that flags unusual entry patterns. The larger platforms lean on third-party integrations for access, without the dispatch-to-completion PIN lifecycle or the sensor-to-ticket and anomaly-detection pieces wired in natively.
| Capability | Rentari.ai | AppFolio | TurboTenant | MagicDoor | Buildium | DoorLoop |
|---|---|---|---|---|---|---|
| Vendor smart-lock PIN auto-issued on dispatch + auto-revoked on completion | Yes | No | No | No | No | No |
| IoT sensor (leak/freeze/smoke) auto-opens a maintenance ticket | Yes | No | No | No | No | No |
| AI anomaly detection on access logs | Yes | No | No | No | No | No |
Based on each vendor's public documentation as of June 2026. Some platforms offer third-party IoT or smart-lock integrations, but not the native sensor-to-ticket flow, the dispatch-to-completion PIN lifecycle, or access-log anomaly detection described here. Rentari's smart-lock and sensor features require the landlord to connect supported hardware (Seam-based).
Why "it revokes itself" matters more than "it issues itself"
Issuing a code is the easy half. Most smart locks let you create a PIN in their own app. The half that actually protects you is the cleanup, and that is the half people skip, because revoking a code is a chore with no deadline. By tying the revoke to the moment a ticket is completed, Rentari makes the boring, security-critical step happen on its own. The vendor's access ends because the job ended, not because you remembered.
That is the through-line for the whole feature. The codes follow the work. The sensors open the tickets. The Doorman reads the log so you do not have to. And every consequential action stays a proposal you approve, so a hands-off system never becomes a system that acts without you.
Take the scorecard with you
This card is the post in one image, the same one we share on Facebook. Save it, or send it to a landlord friend who is comparing tools.
