Re-Send a Failed Webhook Delivery Without Leaving the Portal
What changed: The webhook deliveries dialog could show you that a delivery had failed and offered nothing to do about it — re-sending was only possible through the API with a key. You can now replay a single delivery, or retry every failed one for a webhook, from the dialog itself.
Where to find it: CM sidebar > API Access > Webhooks > the three-dot menu on a webhook > Deliveries.
What you’ll see: A Replay action on each settled delivery, and a Retry failed button showing how many failed deliveries there are. After either, a short message says what happened — how many were re-sent, and how many were skipped because they were already queued. A delivery still being retried automatically shows Replay greyed out until it settles.
What you need to do: Nothing, unless a receiver of yours missed events while it was down — then this is how you get them re-sent. Before using it in anger, check that your endpoint de-duplicates on the X-Nimbio-Delivery header: a replay carries the same event id as the original, so a receiver that ignores that header will act on the event a second time.
Who this affects: Community Managers and Nimbio Admins running a webhook integration
The API Playground Now Covers Every Endpoint Your Key Can Reach
What changed: The Playground on the API Access page listed 15 operations while the public API had grown to roughly 90. Everything added over the last several releases — homes and unit sync, guest links, keypad access codes, GuestView short codes and Entry settings, NFC tags, sense lines, recurring hold opens, community settings, the gate map, per-manager notification settings, and webhook replay — was missing, so there was no way to try any of it without leaving the portal. All of it is now there. It also could not previously send an edit or a delete at all, so those operations would not have worked even once listed; they do now.
Where to find it: CM sidebar > API Access > Playground.
What you’ll see: The operation picker is grouped by area — Reads, Writes, Homes, Guest Links, Access Codes, Webhooks, Logs and so on — rather than one long alphabetical list. Each operation carries the same description and per-field help as the API reference, so you can tell what a field expects without switching to the docs. The curl and JavaScript snippets below the tester now match exactly what it sends, including for edits and deletes.
What you need to do: No action needed. If you tried an operation here before and found it missing, it is worth another look. As before, use a test key to explore safely — opens are simulated and messages are not sent — and note that anything with a real effect is flagged before you run it.
Who this affects: Community Managers, Nimbio Admins, and developers integrating with the API
Turning Event Links Off No Longer Cancels the Ones You Handed Out
What changed: The community’s event-link setting is now a rule about members rather than a switch that kills every event link at once. With event links off, members cannot create them and any event link a member already made stops working — but a link you or a Nimbio admin created keeps working until its window ends or you revoke it. You can also still create an event link while the feature is off, which is what you want when events are run by the office rather than by residents.
Where to find it: CM sidebar > GuestLinks > Links (and the same tab on the admin community page); the setting itself stays on GuestLinks > Settings.
What you’ll see: The Create Link dialog still offers the Event option when the feature is off — it just starts you on Limited Use and explains that members cannot create event links while a link you make here still works. On the Links tab, a short note at the top appears whenever event links are off, saying how many manager-created links are still live and that member-created ones are disabled. Individual links stay labelled as before: a disabled member link shows “Feature off”, a live one shows “Active”.
What you need to do: No action needed. If you turned event links off in the past expecting it to cancel manager-created links, revoke those links individually from the Links tab.
Who this affects: Community Managers, Nimbio Admins
Live Updates Stop Piling Up in a Long-Open Tab
What changed: Anything that refreshes by itself on your pages — gate status, hold opens, member changes — sets up a watch on the server, and those watches were never released when you moved to another page. A tab left open for a long session kept adding more of them, doing steadily more background work for the same information, and could occasionally reload information belonging to a page you had already left.
Where to find it: Everywhere in the community manager pages — no specific screen.
What you’ll see: Nothing different in how the pages look or work; they simply stop accumulating watches as you move around. The Hold Opens page had its own version of the problem — it re-watched every gate each time the list reloaded without releasing the previous set — and now releases them properly and re-establishes them after your phone or laptop reconnects, so hold-open changes keep arriving live instead of going quiet.
What you need to do: No action needed. If you have had a tab open since before this release, reload it once.
Who this affects: Community Managers
Accurate Member Count When Scheduling the Community Key
What changed: The confirmation shown before you put a schedule on your community’s main key counts how many members it will affect. That count included keys that had already been revoked or removed, so it overstated the impact.
Where to find it: CM sidebar > Keys > three-dot menu on the community key > Access Schedule
What you’ll see: A smaller, correct number in the confirmation — one community was told 1,115 members where the true figure was 804.
What you need to do: No action needed.
Who this affects: Community Managers