Revoked keys get a clear 403 — including on the event stream
What changed: A key whose manager has lost API access is now refused with 403 api_access_revoked (plus an error.reason) on every community endpoint. Previously some reads returned an empty 200 {} that looked like an empty community. The live event stream now checks access when it connects and about once a minute while open, and webhooks registered by that manager stop delivering.
Where to find it: Every /v1/community/... endpoint and GET /v1/events/stream
What you’ll see: 403 {"detail": {"error": {"code": "api_access_revoked", "reason": "not_a_manager", ...}}} instead of empty data; on an open stream, a final stream.revoked frame followed by the stream closing.
What you need to do: Treat api_access_revoked as “stop and ask a current manager for a new key” rather than retrying. If you listen to the event stream, handle stream.revoked by not reconnecting in a loop.
Who this affects: Customers
Member keys report expiry
What changed: Member-key objects now carry expires_at, expires_at_valid and installer_grant, and member rows carry installer_grant. Purely additive — disabled is unchanged.
Where to find it: GET /v1/community/members, the paged member read, and the single-member read
What you’ll see: Three new fields on every member key. Nothing existing changes shape or meaning.
What you need to do: Nothing is required. To tell whether a key is currently in force, read expires_at_valid; disabled continues to mean “revoked” and a lapsed key still reports disabled: false.
Who this affects: Customers
A Delivery PIN That Works Without Picking a Name
What changed: A community’s access codes can now run in one of two systems, and the API reads and switches between them. In the original per-member system a visitor must find the resident in the GuestView directory before typing that resident’s code — which meant a PIN minted through the API could only be redeemed under the key owner’s own directory entry, the limitation the access-code endpoints shipped with. In the new single-entry system there is one “Enter access code” field for the whole community: every member carries a 3-letter preamble derived from their name, unique within the community, and the visitor types preamble plus code — ESM481502 — with no name to find. That is the code-only redemption integrators have been asking for, and a code your integration mints now comes back with the full string to hand out.
Where to find it: GET and PUT /v1/community/access-codes/mode, under Community · Access Codes in the API reference at api.nimbio.com/docs. The existing POST /v1/community/access-codes now returns entry_code beside code, and the list reports each code’s preamble.
What you’ll see: The read returns the mode in force and a costed preview of switching to the other one — how many codes a switch would delete, how many members would lose at least one, and how many would be given a preamble. The write is a two-step handshake, the same one the NFC-tag endpoints use: send the new mode and you get back a 409 with that preview and nothing changes; send it again with confirm: true and the switch happens, reporting how many codes were deleted and how many members were notified. Sending the same mode the community already runs is a harmless 200. Test-mode keys run the whole handshake and then report what would have changed, touching nothing.
What you need to do: Understand one thing before you call the switch: it deletes every access code in the community, in either direction — the ones your key minted, the ones other integrations minted, and the ones residents made for themselves in the app — because a code’s meaning changes with the system. Affected residents are notified automatically and a community-wide message explains the new system, but their codes are gone and they will create new ones. Show the preview to a person before you confirm, and never wire confirm: true into an unattended path. The switch is deliberately its own endpoint and not part of the community settings call, so a routine settings update can never trigger it; the settings read reports the current mode as read-only. If your community stays on the per-member system, nothing changes — the new response fields are simply null.
Who this affects: Customers (developers and integrators) building on the Nimbio API, and Community Managers with API access — particularly anyone issuing delivery or contractor PINs.