Open Notes Are Now Kept — and Show Up in the Access Log
What changed: Every open endpoint has always accepted an optional note in the request body, and the documentation said it was recorded with the open. It wasn’t — the note was read and then discarded, so every note ever sent was lost. Notes are now stored with the open and shown wherever that open appears.
Where to find it: Send {"note": "..."} on POST /v1/community/latches/{latch_id}/open, POST /v1/account/keys/{key_id}/latches/{latch_id}/open, or POST /v1/keys/{key_id}/latches/{latch_id}/open. Read it back on GET /v1/calls, GET /v1/calls/{request_id}, and as api_note on GET /v1/community/access-logs — and on the Access Logs page community managers use.
What you’ll see: The note travels with the open. It is kept on refused opens too, so a denied or timed-out open still carries the note explaining what the caller was trying to do — often exactly the row someone is trying to understand later. Notes are trimmed and capped at 500 characters, and a malformed note is ignored rather than failing the open.
What you need to do: Nothing. If your integration already sends note, it starts being kept from this release — a good place to record why an open happened (“delivery van at side gate”, “opened for fire inspector”) so the community manager reading the log later can tell.
Who this affects: Customers, Community Managers
Key Access Schedules
What changed: Three new endpoints let an integration read and set when a key may open its gates: GET /v1/community/key-schedules, GET /v1/community/keys/{key_id}/schedule, and PUT /v1/community/keys/{key_id}/schedule.
Where to find it: API reference > Community · Access Schedules. A new key_schedules capability appears on /v1/me.
What you’ll see: A schedule is a list of windows, each {days_of_the_week, start_time, end_time} — days as letters from MTWHFSU (H is Thursday, U is Sunday), times as "HH:MM" in each gate’s local time. The PUT replaces the whole schedule, and {"windows": []} removes every restriction. Responses separate restricted from permanently_blocked, and carry descendant_key_count so you know how many member keys a change will affect before you make it. Reads don’t count against the monthly quota; test keys validate without changing access. Validation failures return a machine-readable code such as overnight_not_supported.
What you need to do: No action needed unless you want to manage schedules — existing keys are unrestricted.
Who this affects: Customers, Community Managers
Live Event Stream — Push Without Webhooks
What changed: The API now offers a live event stream: your integration opens one outbound connection to GET /v1/events/stream and receives every community event — gate status changes, hold-open changes, opens, device online/offline, member changes — the instant they happen. It’s the same event feed webhooks deliver, but nothing has to be exposed to the internet, so it works from behind any home or office network.
Where to find it: GET /v1/events/stream (community API keys), documented at api.nimbio.com/docs; both official SDKs wrap it (stream_events() in Python, streamEvents() in npm).
What you’ll see: A standard Server-Sent Events stream. If your connection drops, reconnecting with the last event id replays what you missed from a short buffer; the stream tells you explicitly when a gap couldn’t be replayed so you can re-sync. Heartbeats keep the connection verifiably alive.
What you need to do: Nothing for existing integrations — webhooks and polling keep working. To go live-push, open the stream with your community key; it doesn’t consume your monthly quota.
Who this affects: Community Managers and integration developers (including Home Assistant users, where the stream is now the default connection mode).
Hold-Open Control from the API
What changed: Community API keys can now read and control hold opens: see each gate’s live hold-open state, flip the manual hold-open on or off, and schedule a one-time “hold open until…” window — the same controls community managers have in the portal.
Where to find it: New endpoints under /v1/community/hold-opens and /v1/community/latches/{latch_id}/hold-open, documented at api.nimbio.com/docs.
What you’ll see: A hold-opens read that mirrors the CM portal (manual toggle, one-time windows, recurring schedules, and the combined “held open” truth per gate), plus write endpoints that respect your community’s Hold Opens setting and show up in the portal’s hold-open change log (“via API”).
What you need to do: Nothing for existing integrations. To use it, call the new endpoints with a community API key; test keys validate everything without moving a gate.
Who this affects: Community Managers and integration developers.
Register Webhooks with Your API Key
What changed: Integrations can now manage their community’s outbound webhooks directly with the API key — list event types, register a receiver, rotate the signing secret, send a test ping, and clean up after themselves — without a human stepping into the admin portal.
Where to find it: New endpoints under /v1/community/webhooks (plus /v1/community/webhook-events for the catalog).
What you’ll see: Webhooks created through the API appear in the portal’s API Access → Webhooks tab like any other. There’s also a new subscribable event, hold_open.changed, that fires whenever a gate’s hold-open state changes.
What you need to do: No action needed. Setup flows (like the upcoming Home Assistant integration) will use this automatically.
Who this affects: Community Managers and integration developers.
Status Polling No Longer Burns Your Quota
What changed: The cheap status reads — gate status, key statuses, hold opens, and /v1/me — no longer count against your key’s monthly quota. The per-minute rate limit still applies.
Where to find it: Automatic on GET /v1/community/gate-status, GET /v1/community/key-statuses, GET /v1/community/hold-opens, and GET /v1/me.
What you’ll see: Your monthly usage counter stops climbing from routine polling; the X-RateLimit-* headers keep reporting real usage.
What you need to do: No action needed.
Who this affects: Integration developers, especially anyone polling status (smart-home dashboards, monitoring).
Smarter Key & Gate Discovery
What changed: GET /v1/me now returns a capabilities list describing exactly what your key can do, and gate-status responses include each gate’s configured status vocabulary (possible_statuses) so an integration can tell a Locked/Unlocked door from an Open/Closed gate without guessing.
Where to find it: GET /v1/me and GET /v1/community/gate-status.
What you’ll see: New fields on existing responses; nothing changes for clients that ignore them.
What you need to do: No action needed.
Who this affects: Integration developers.