Replay a Webhook Delivery Your Receiver Missed
What changed: When a webhook delivery fails — your server was down, a deploy window swallowed it, DNS blipped, your endpoint returned a 500 — you can now re-send it once your receiver is fixed, either one delivery at a time or every failed delivery for a webhook in a single call. Delivery history already let you see that an event never landed; this is the half that lets you do something about it.
It matters more for webhooks than it would for most of the API, because a missed event cannot be recovered by polling. The rest of the API reports current state — who is a member now, which gate is open now — not the stream of things that happened. A gate open that never reached you is a permanent hole in your history, and no amount of re-reading the members or access endpoints fills it back in. Until now the only remedies were to re-derive the state by hand or to ask Nimbio to intervene.
Where to find it: POST /v1/community/webhooks/{webhook_id}/deliveries/{delivery_id}/replay and POST /v1/community/webhooks/{webhook_id}/deliveries/retry-failed, under Community · Webhooks in the API reference at api.nimbio.com/docs. The delivery id comes from GET /v1/community/webhooks/{webhook_id}/deliveries, which is where you find the failure in the first place.
What you’ll see: The re-sent delivery arrives at your endpoint carrying the same event id and the same content as the original attempt — it is the exact message Nimbio stored the first time, re-sent, not a reconstruction of it. Both the original failure and the replay stay visible in your delivery history side by side: the failed attempt keeps its error, its status code and its attempt count, and the replay appears next to it as a fresh pending delivery. Nothing is overwritten, so the record of what went wrong survives the fix.
The bulk call reports exactly what it enqueued rather than a bare success — how many deliveries were re-sent, which originals they came from, and how many were skipped because Nimbio was already retrying them or because they duplicated an event already in the batch. It re-sends oldest first, so a run of missed events reaches you in the order they originally happened. Two other behaviours are worth knowing: a replay can never race Nimbio’s own retries — while an event is still being retried, a replay of it is refused rather than double-fired — and if your webhook was automatically switched off after repeated failures, both calls refuse until you re-enable it, rather than quietly queueing sends that would be thrown away.
What you need to do: Before you replay anything, confirm your handler de-duplicates on event id. A replay deliberately keeps the original event id, and the X-Nimbio-Delivery header on every delivery carries that event id, not the delivery id. If your code already checks that header and skips events it has seen, a replay is safe and does the right thing. If your code ignores it, replaying will apply the same event a second time — a second charge, a second provisioning run, a second gate open. Check that first, then replay one delivery and confirm the result before you reach for the bulk call.
Two more things to do before you rely on it. If your webhook was disabled after repeated failures, re-enable it first (set active to true on the webhook) — the replay endpoints refuse a disabled webhook, and they say so distinctly, so treat that response as “re-enable the webhook”, not as an API-key problem. And if you have rotated your signing secret since the original attempt, know that the replay is signed with your current secret, not the one in force when the event first fired — a receiver still validating against the old secret will reject it.
Otherwise no action is needed. These are new capabilities, nothing changes for existing integrations, and your existing API key already works with them. Test-mode keys report what they would have done and send nothing, because a replay puts a real event in front of a real receiver.
Who this affects: Community Managers with API access, Customers (developers and integrators) building on the Nimbio API, and anyone running a webhook consumer that has ever missed an event.
Recurring Hold-Open Schedules Are Finally Writable
What changed: The repeating hold-open schedules that keep a gate open on business hours, on trash day or during a standing delivery window can now be created, changed and deleted through the API. Until now the API could only read them — the schedules and the “pause until” date showed up in every hold-opens response, and nothing an integration could call would change either. That read-only half is now closed.
Where to find it: The recurring hold-open endpoints on /v1/community/latches/{latch_id}/hold-open, under Community · Hold Opens in the API reference at api.nimbio.com/docs.
What you’ll see: A schedule created over the API appears on the Community Manager portal’s Hold Opens page like any other, and one created in the portal can be edited over the API — the identifier is the same on both sides, so a schedule can be read, changed and written back without translating anything. A second call suspends every scheduled hold open on one gate until a moment you choose — the holiday, the closure, the special event — releasing any hold already active, skipping the schedules while it is in force, and clearing itself when the moment passes. One call with an explicit “resume” value lifts it early.
Three things to design around, because each one has bitten someone. Days are letters, and they are not the letters you expect: H is Thursday, S is Saturday, U is Sunday — they are the same letters the API already hands back, so read a schedule before writing one and the encoding answers itself. Times are in the gate’s own local time, never UTC and never yours; a community with gates in two timezones runs each schedule on its own gate’s clock. And a window cannot run past midnight — a 10pm-to-6am schedule is written as two, one ending at end-of-day and one starting at midnight, which the API tells you plainly if you try it the other way. Deleting a schedule that isn’t there is reported as an error rather than shrugged off, on purpose: quietly succeeding would let your system believe it had cancelled something that is still holding a gate open.
What you need to do: No action needed. Nothing changes for existing integrations, and existing schedules are untouched — these are new capabilities, not new requirements.
Who this affects: Community Managers, Customers running scheduling, facilities or property-management systems, and developers building on the Nimbio API.
Configure a Community Without Asking Anyone to Open the Portal
What changed: A community’s feature switches and the words it uses for members and homes can now be read and changed over the API. Provisioning a property used to stop dead at “ask someone to go flip a switch”; a whole configuration profile can now be applied in one call.
Where to find it: GET and PATCH /v1/community/settings, under Community · Settings in the API reference at api.nimbio.com/docs.
What you’ll see: The read returns everything you may change, the community’s resolved member and home labels, the label choices its property type offers, and — separately — the features Nimbio has provisioned for that community. That last block is the point of reading: several whole families of endpoints are switched on or off by those flags, and without this call the only way to discover a feature is off is to call it and be refused. Your code can now check first and branch.
The write applies only the keys you send and leaves everything else alone. It is validated as a whole before anything is saved, so a batch containing one bad value changes nothing — there is no half-applied profile to reason about or unwind. A key it does not recognise is rejected and named, never quietly ignored, because silently dropping a typo is how a system comes to believe it configured something it did not.
A few settings are read-only, and that is a provisioning boundary rather than a limit of the API. Hold Opens, Access Log History, GuestView Entry and the two per-community limits on guest links and event keys are Nimbio-side decisions — a community manager cannot change them from the portal either. Rather than pretending those keys are unknown, the API reports them and, if you try to set one, explains exactly which it is and that it is ours to turn on. Ask us and we will.
What you need to do: No action needed — the endpoints are additive and nothing changes for existing integrations. If you provision properties programmatically, read the settings first and branch on the provisioned-feature block instead of calling an endpoint to see whether it refuses you. And remember that these settings change what the rest of the API does: switching the directory off makes it disappear for members and guests, and denying event keys stops them working community-wide.
Who this affects: Community Managers with API access, Customers provisioning properties from their own systems, and developers building on the Nimbio API.
Put Your Gates on Your Own Map
What changed: An integration can now read where a community’s gates physically are — the community’s location, each Nimbio device’s location, and each gate’s arrival geofence — and set those geofences itself, instead of a person dragging pins in the portal one at a time.
Where to find it: GET /v1/community/map and the geofence write on /v1/community/latches/{latch_id}/geofence, under Community · Map & Geofences in the API reference at api.nimbio.com/docs.
What you’ll see: Coordinates for the community and for every device, and for each gate the fence it advertises to the Nimbio apps: whether it is on, its centre, its radius in metres, and whether arriving should prompt the member to open the gate or open it for them. A gate that has never had a fence configured says so, and offers its device’s location as the sensible starting point. For a home-automation integration this is what turns a list of gate names into a set of real places — a zone per gate, with the same radius the Nimbio app uses.
Two rules worth knowing before you automate it. The radius is in metres and 100 is the floor — a smaller fence is refused rather than quietly rounded up, because phone geofencing degrades below about that distance and a smaller fence would look configured and never fire. And the write only changes what you send: there is deliberately no way to erase a configured centre through this endpoint, because doing that by accident would switch off a real gate’s proximity behaviour with nothing anywhere to show for it.
What you need to do: No action needed. Existing geofences are unchanged and existing integrations are unaffected. One caution if you consume the map: it says exactly where a property’s entrances are, so treat the response as the security information it is.
Who this affects: Community Managers, Customers building home-automation or mapping integrations, and developers building on the Nimbio API.
Your Own Gate Alerts, and the Hours You Don’t Want Them
What changed: The alert a community manager gets when a member opens a gate — and the quiet hours that mute it — can now be read and set through the API.
Where to find it: The /v1/community/my-notification-settings endpoints, under Community · My Notifications in the API reference at api.nimbio.com/docs.
What you’ll see: Whether alerts are on, whether the community allows them at all, and the list of quiet-hours windows, returned in full by every one of these calls so there is never a second call to find out what you just did. Windows are days of the week plus a start and end time, and they are the one place on this surface where a window may run past midnight — 10pm to 6am is a single window here, unlike gate schedules, which must be split. Each window is judged in the local time of the gate that was opened, so a community with gates in two timezones mutes each gate’s alerts on that gate’s own clock. Adding is one call per window and removing is one call per window; there is no “replace the whole schedule” call, so to change a schedule, delete the windows you no longer want.
The most important thing about this surface: these settings belong to a person, not to a community. An API key acts as the community manager who owns it, so these calls always read and write that manager’s preferences. A community with several managers has several independent settings, and two keys owned by two different managers of the same community will see two different answers here. Switching alerts off through one key does not quiet anyone else. If you have been thinking of this as a community-wide switch, it is not one — and the endpoint is named “my” for exactly that reason.
What you need to do: No action needed. If you are building against it, decide deliberately which manager’s key your integration holds, because that is whose alerts it is managing. The community’s member-open notifications feature also has to be switched on before any of the writes will work; the read tells you whether it is.
Who this affects: Community Managers with API access, and developers building on the Nimbio API.
Kill a Lost Fob From Your Own System
What changed: A community’s NFC fobs and cards can now be listed, moved to a different gate, detached, disabled and re-enabled through the API, and the full tap history can be read. The time-critical case is the one that matters: a fob reported lost can be killed the moment the report comes in, by the property’s own system, instead of by hand in the admin portal.
Where to find it: The /v1/community/nfc-tags endpoints, under Community · NFC Tags in the API reference at api.nimbio.com/docs.
What you’ll see: A searchable, paginated list of the community’s tags — searchable by serial, by the fob’s printed identifier, or by whatever notes are on it — and a single update call that assigns, detaches or disables, so a caller reacting to a lost fob doesn’t have to work out which operation applies. Disabling takes effect for real taps at real gates: the next tap is refused. Alongside it, the scan log shows every tap the community has recorded — which fob, which gate, what happened, when, and who the tapper was where the tap resolved to a person — which is what makes “this fob was used after it was reported lost” a question you can actually answer.
One safeguard: if disabling or moving a tag would leave a scan-only gate with no working tag, the call comes back asking you to confirm rather than doing it silently. It is a warning, not a veto — repeat the call with confirmation and it proceeds, because revoking a stolen fob has to stay possible even when it is the last one.
What you need to do: Nothing unless you integrate. Two things to know if you do. Fobs are bound to gates, not to people — a tag opens the gate it is assigned to, for whoever is holding it — so treat a lost fob as a gate credential, not as one person’s key. And programming a blank fob remains an operator job done in person with a card reader; these endpoints manage tags that already exist. No cryptographic tag material is ever returned by the API, and a tag’s notes are readable but not writable here.
Who this affects: Community Managers with API access, Customers running property-management or resident systems, and developers building on the Nimbio API.
Find Out Why a Gate Always Reports Closed
What changed: The physical sensors underneath a gate’s reported status — the wires that tell Nimbio whether the gate actually moved — can now be read through the API, along with their raw reading history and their configuration. When a gate’s status looks wrong, the layer beneath it is now visible instead of being a support ticket.
Where to find it: The /v1/community/sense-lines endpoints, under Community · Devices in the API reference at api.nimbio.com/docs.
What you’ll see: For each sensor: whether it is switched on, whether its readings are allowed to drive the gate status your integration reads, and a single derived answer for whether it is actually reporting — which is true only when both of those are on. A gate frozen on one status with that answer showing false is a configuration problem, not a stuck gate, and that distinction is usually the whole diagnosis. Alongside it: a plain map of what each raw reading means for that gate, when the sensor last reported anything, and a history of the raw readings themselves.
That history is the part that settles arguments, because readings are recorded even while a sensor is switched off. A healthy stream of readings next to a gate status that hasn’t moved in a week is proof the wiring is fine and the configuration is not. And a reading with no configured meaning is returned as exactly that rather than being dropped, because an unmapped reading is itself a finding.
What you need to do: No action needed — the existing gate-status endpoints are unchanged. If you diagnose gates programmatically, note that a sensor is identified by its device and its number: sensor numbers repeat across devices, so “sensor 1” needs to say which device.
This surface is meant for reading, by design. You can correct a sensor’s configuration through it — switching a miswired input off is a legitimate repair — but the API cannot write what a gate is observed to be doing. Observed state comes from the hardware and stays that way. Be deliberate with the configuration write: switching a sensor off freezes its gate’s reported status at its last known value everywhere — the apps, the API, and the webhook that fires on gate movement — and affects hold-open behaviour that reads gate state.
Who this affects: Community Managers running their own integrations, Customers with monitoring or facilities systems, and developers building on the Nimbio API.
Issue a Guest’s Gate Link the Moment a Booking Is Confirmed
What changed: The API can now create, list, revoke and audit guest links — the shareable links that let someone open a gate without a Nimbio account and without ever being given a key. A booking system, a vacation rental platform or a property-management tool can now issue a guest’s gate link the instant the reservation is confirmed and kill it at checkout, instead of a manager opening the portal for every arrival.
Where to find it: The /v1/community/guest-links endpoints, listed under Community · Guest Links in the API reference at api.nimbio.com/docs.
What you’ll see: Two kinds of link, matching what the portal offers. An event link is live between a start and an end time and allows unlimited opens in between — the link you hand out for a party, a viewing or a contractor’s morning. A limited-use link is live until a set number of opens has been consumed, with an expiry date as a backstop — the link you hand a guest for a three-night stay. Both come back with a ready-to-send URL, so there is nothing to assemble at your end, and a separate call reports every attempt made against them: who opened what, when, and which attempts were turned away.
Three things to know before you automate it. The guest URL is not one-time — it is returned again every time you list your links, so a guest who lost their link can be sent it again, and equally, anyone who can read that listing can open those gates. Treat it like a password. Revoking is permanent: there is no un-revoke and no edit, so a change of plan means revoking the link and issuing a new one. And there is a cap of 25 live links per community manager, per link type, counted against the manager your API key acts as — including links that person created in the portal — so an integration should revoke links it no longer needs rather than letting them expire on their own.
One deliberate widening worth knowing about: a community can switch event keys off for its members, and that switch has never applied to a community manager acting on the management surface — it exists so that turning the feature off does not silently break the links a manager already handed out for tonight. Because an API key acts as its owning community manager, an API key can still issue an event link for a community with event keys switched off. If your integration should respect that setting, read the community’s feature flags and decide for yourself; the API will not decide for you.
What you need to do: Nothing unless you are building an integration. If you are, pick the gates the link should cover from the community’s own list, choose a link type, and hand the returned URL to your guest. Which gates each link type is allowed to cover is set in the community manager portal and is read-only over the API for now — that control narrows what a link can ever reach, so opening it to integrations is being reviewed on its own.
Who this affects: Community Managers, Customers running booking or rental systems, and developers building on the Nimbio API.
Visitor Gate PINs, Issued and Revoked by Your Own Systems
What changed: Access codes — the PINs a delivery driver, vendor or contractor types at a keypad or in GuestView — can now be created, listed, changed and deleted through the API. A work-order or delivery system can mint a PIN for a scheduled visit and switch it off when the job is done, without anyone opening the portal.
Where to find it: The /v1/community/access-codes endpoints, under Community · Access Codes in the API reference at api.nimbio.com/docs.
What you’ll see: A created code comes back with its PIN, the gates it opens, and its expiry. You can list every code in the community — including ones residents made themselves, exactly as the portal shows them — read the full redemption history, and read the list of gates the community has allowed access codes to open. Each code can carry an absolute cutoff (hours or days from now), a recurring weekly window such as weekdays 9-to-5, or both, and the weekly window is judged in the gate’s own local time, not yours.
The single most important thing about this surface: the PIN is shown once, when you create it, and never again. Every later read masks it completely — asterisks, not the last few characters, because a four-character PIN with two characters revealed is down to a hundred guesses. There is no reveal call and no recovery: if your system does not store the PIN at the moment it creates it, the only way back is to delete the code and issue a new one. Build for that from the start.
What you need to do: Turn on Directory Access Codes for the community and choose which gates codes may open in the portal first — both are portal settings the API reads but cannot change. Then, if you are building an integration, capture the PIN from the create response and deliver it to your visitor there and then. Note that the API can only change or delete the codes belonging to the community manager it acts as; a resident’s own PIN stays theirs, and stays a portal job.
Who this affects: Community Managers, Customers running delivery, work-order or vendor-management systems, and the developers integrating them.
Set When Guests May Let Themselves In, From Your Own System
What changed: GuestView Entry — the feature that lets a phone-verified visitor standing at a gate open it themselves from the community directory — is now fully manageable over the API. A visitor-management or front-desk system can read the whole configuration, switch the feature on or off, choose which gates it covers, set the hours it is permitted, and read every attempt.
Where to find it: The /v1/community/guest-view-entry endpoints, under Community · GuestView Entry in the API reference at api.nimbio.com/docs.
What you’ll see: One call returns the complete picture — whether the feature is on, which gates it covers, and every recurring time window — and every change returns that same complete picture back, so there is never a second call to find out what you just did. Windows are set as days of the week plus a start and end time, and each one is judged in its own gate’s local time: 9-to-5 on a gate in Los Angeles means Pacific, and the same window on a gate in New York means Eastern. Reading the attempt log keeps working even after the feature is switched off, so the history of who came in that way is never lost.
Two behaviours to design around. Setting the list of covered gates replaces it entirely — send the full list every time, because any gate you leave out loses guest entry and its time windows are deleted with it. And a gate with no time windows at all is open to guests around the clock: the windows are a list of permitted hours, not blocked ones, so the first window you add is what starts restricting a gate, and deleting a gate’s last window opens it back up. Removing a window widens access rather than narrowing it.
What you need to do: No action needed — nothing changes for existing integrations or for communities that manage this in the portal. If you are building a visitor-management integration, read the settings first, then set gates and windows explicitly rather than assuming a default.
Who this affects: Community Managers, Customers running visitor-management or front-desk systems, and developers building on the Nimbio API.
Generate Your Gate Signage Without Retyping Codes
What changed: The short codes that send a visitor to your GuestView directory — the code printed on a gate placard — can now be read, created and repointed through the API. A property can be provisioned and its signage generated end to end without anyone copying a code out of the portal by hand, which is the step that produces wrong placards.
Where to find it: The /v1/community/short-codes endpoints, under Community · Short Codes in the API reference at api.nimbio.com/docs.
What you’ll see: Every code comes back with the gate it routes to and that gate’s name, so a sign can be rendered or verified in a single call. You can let Nimbio generate a code for you or claim a specific one, and you can repoint an existing code at a different gate — moving a placard from one entrance to another without reprinting it.
The thing that will shape your design: short codes are unique across all of Nimbio, not just within your community. The code itself is what routes a visitor to the right place, so there is one shared namespace, and a code already in use anywhere — including one that differs only in capitalisation — is refused. That means a tidy per-property scheme like MAPLE01 cannot be assumed to work: it may already belong to a community you will never see, and there is no way to check availability other than asking for it. The reliable pattern is to let Nimbio generate the code and print what it hands back; if you want a specific one, be ready for the answer “already taken, pick another”.
What you need to do: Nothing, unless you generate signage programmatically. If you do, one further point matters: short codes cannot be deleted — not through the API and not in the portal — so mint them deliberately. A code you create is permanent, and the most that can be done to retire one is for Nimbio to disable it.
Who this affects: Community Managers, Customers provisioning properties or producing signage in bulk, and developers building on the Nimbio API.
Approve Members Through the API
What changed: An integration that is told someone wants to join a community can now approve them directly, instead of handing off to a person. Until now the API could report a join request and list who was waiting, but the approval itself only existed as a button in the portal — so the “member approved” notification other systems subscribe to was something no integration could ever cause.
Where to find it: POST /v1/community/members/{account_community_id}/approve, in the API reference at api.nimbio.com/docs under Community · Writes.
What you’ll see: The member moves out of the pending list, receives a key on their account for each community key you name, gets the same approval notification on their phone as a portal approval sends, and your member.approved webhook fires. An approval made through the API is indistinguishable from one a community manager made by hand. Approving somebody who is already approved comes back as its own distinct “already a member” answer, plainly separate from “your request was wrong”, so it is safe to replay a join-request notification or to race a manager working in the portal.
What you need to do: Nothing unless you are building an integration. If you are, call it with the community key ids the new member should get; a move-out date is optional, and a dry run validates everything without approving anyone.
Who this affects: Community Managers with API access, and developers building on the Nimbio API.
Sync Your Unit Roster From Your Property-Management System
What changed: The API can now list, add, edit, and remove the homes that make up a community, and read which residents are attached to each one. A property-management system is the system of record for the unit roster, and until now none of that roster was reachable over the API — a manager retyped every new unit into the portal by hand, and an integration could not even read what Nimbio already had, so reconciling the two was impossible.
Where to find it: The /v1/community/homes endpoints, listed under Community · Homes in the API reference at api.nimbio.com/docs.
What you’ll see: One call returns the whole unit list with a resident count per unit; one returns a single unit with the people living in it and their move-out dates. Adding a unit hands back the finished record, so a sync can record it without a second call. Editing takes the address, the owner-occupied flag, and the hidden flag independently, so correcting an address never disturbs the flags you did not touch.
Two things to know before you automate it. Removing a unit unlinks every resident living in it — they stay members of the community and keep their keys, but they are no longer associated with any unit, and nothing puts that back: re-creating the unit creates a new one, and every resident would have to be re-attached by hand. The response tells you how many people it just unlinked, you can read the resident list first, and a test key will tell you the count without changing anything. Separately, hiding a unit is now genuinely reversible: hiding has always been a one-way door in Nimbio, with no way to bring a hidden unit back anywhere in the product, and the API is now the only place that can un-hide one. Setting the flag to the same value twice leaves it where it is, so a retried request is safe.
What you need to do: No action needed unless you run a property-management system alongside Nimbio. If you do, this is the integration point: push new units as they come online, correct addresses in place, and reconcile against the live list instead of trusting your own copy.
Who this affects: Community Managers and Customers running a property-management system, and the developers integrating one.
Move-Out Dates Over the API
What changed: A resident’s move-out date can now be recorded, or cleared, through the API, so their access lapses on schedule instead of depending on someone remembering to revoke it when a lease ends.
Where to find it: PUT /v1/community/members/{account_community_id}/move-out-date, grouped with the unit-roster endpoints under Community · Homes.
What you’ll see: The date is stamped on the membership exactly as it is when a community manager sets it in the portal, and it shows up on that resident when you read their unit. Sending an empty value clears it.
What you need to do: No action needed. If your leasing system already knows when a tenancy ends, send that date when the lease is signed and the access takes care of itself.
Who this affects: Community Managers, and the Customers whose leasing systems drive them.
Bulk Member Operations
What changed: Adding members, and granting, revoking, or disabling their keys, can now be done for up to 100 members in a single call. Every member change used to be one call each, which made a large roster sync impractical: importing 500 members meant 500 calls in a row against a per-minute allowance, and a client that simply worked through the list ran out of allowance about twelve seconds in — with 60 members applied, 440 not, and no way to tell from the response which 60 had landed. The same import is now five calls.
Where to find it: The bulk endpoints on /v1/community/members (bulk-add, and keys/bulk-grant, keys/bulk-revoke, keys/bulk-disabled), in the API reference under Community · Writes.
What you’ll see: The behavior is two-stage, and the difference matters when you write the client.
First, the whole batch is validated before anything is applied — and a validation failure rejects the entire batch, with nothing changed. A member or key belonging to a different community, a duplicate entry, a batch over the 100 limit, or an item missing a key all fall here, so a bad import is refused at the door rather than half-applying and discovering the problem at row 300.
Only after that does execution begin, and there the outcome is reported per item: every entry comes back in the order you sent it, stamped with the id you sent, so you can line the results up against your input and re-send just the ones that failed. Re-sending is safe — granting a key someone already holds, or revoking one they no longer have, is reported as already-done rather than as an error.
The one thing not to get wrong: a processed batch always answers with HTTP 207 Multi-Status, whether every item worked, some did, or none did — 207 does not mean everything succeeded, and a client that treats it as a plain success will silently drop failures. The answer is in the response body, which carries a per-item result and a summary count. The constant status is deliberate: one that changed with the outcome would invite code that checks for 200 and quietly treats a partly-applied batch as clean.
What you need to do: Nothing for existing integrations — the single-member endpoints are unchanged and still work exactly as before. If you sync rosters, switch your imports and nightly reconciliation to the bulk endpoints, and make sure your client reads the body rather than the status code. Two things to plan for: a bulk call costs one unit of monthly quota per member in it (the same as sending them one at a time — it saves you calls, not quota), and bulk-add is the highest-impact call on the API, since each member it adds may create a Nimbio account, mints keys, sends that person a push notification, and fires a webhook, none of which can be undone. A live 100-member add does all of that 100 times in one burst, so size your receiver for it before you point this at a 500-row spreadsheet.
Who this affects: Customers building integrations, and the Community Managers whose rosters they sync.
Community Key Management Over the API
What changed: Integrations can now rename a community’s own key, and disable or re-enable it, without a human in the admin portal — the operation you need when a key is compromised or a contractor’s access has to be cut immediately. The API could already see a community’s keys and change one member’s access; it could not touch the community’s keys themselves.
Where to find it: PATCH /v1/community/keys/{key_id} in the API reference, under Community · Writes.
What you’ll see: The updated key comes back in the same shape the key listing returns, so nothing needs re-reading, along with a count of how many member keys the change reached.
What you need to do: No action needed unless you want to automate incident response. If you do, know what the lever does: disabling a community key cuts off every member holding a key shared from it — potentially the whole community at once. That is the point of it, and the response tells you how many keys it reached. It is fully reversible by the same call, and your API key’s access does not depend on the key you disabled, so you cannot lock yourself out of turning it back on. To cut one member instead of everybody, use the endpoint that disables a single member’s keys. Renaming is cosmetic: it changes what members see and how the access logs label an open, never who can open what.
Who this affects: Community Managers with API access, and developers building on the Nimbio API.
Community Discovery — One Call That Describes the Community
What changed: A single new API call describes the community an API key is bound to — its name and property type, the timezone its timestamps are in, every gate with its id, which features it has turned on, what it calls its members and homes, and how many of each it has. Previously an integration had to hardcode the timezone and discover features by calling an endpoint and interpreting the 403 it got back.
Where to find it: GET /v1/community, listed first under Community · Reads in the API reference at api.nimbio.com/docs.
What you’ll see: One response carrying the community’s identity, its timezone, the id and name of every gate, a features object of on/off flags, the community’s own labels for members and homes, and member and gate counts. The gate ids are the same ones every open call takes, so this is where an integration gets them. Where a community spans sites whose gates sit in different timezones, the top-level timezone is null and each gate reports its own.
What you need to do: No action needed for existing integrations. New ones should call this first — it supplies the gate ids every open needs, removes the guesswork about which clock the community’s timestamps are in, and lets you branch on features instead of probing. It doesn’t count against your monthly quota, so it’s safe to call on startup and whenever configuration might have changed.
Who this affects: Customers (developers and integrators)
Configuration Audit Trail on the API
What changed: Integrations can now pull the record of who changed a community’s access configuration — hold opens, key access schedules, GuestView/Directory settings, and guest links — over the API, instead of reading it in the portal. This is the change trail, distinct from the access trail: the access log tells you a gate opened, this tells you someone rewrote the schedule that let it open.
Where to find it: GET /v1/community/change-logs, with a required type naming which of the four trails to read (API reference → Community · Logs).
What you’ll see: Each entry names the manager who made the change, when they made it, what kind of change it was, and a plain-language summary, along with the gate or key it affected. Rows come back newest first and page with limit and offset. Every trail keeps 30 days, and asking for more is quietly trimmed to 30 with the window you actually got reported back — so export on a schedule if you need a longer archive.
What you need to do: No action needed. Existing community API keys already have access, and a new change_logs capability appears on /v1/me. Nothing changes for anyone not using the API.
Who this affects: Community Managers and integrators, particularly those with compliance, insurance, or security-review obligations that require an exportable configuration audit trail.
Key Usage History Report
What changed: Integrations can now pull the same per-key usage report a community manager sees on the portal’s Access Logs page, for any date range they choose, instead of only the rolling 90 days of raw events.
Where to find it: GET /v1/community/key-usage (API reference → Community · Logs).
What you’ll see: One row per gate open with the key, gate, local timestamp, and how it was opened, plus a report_type telling you whether this community names individual openers (commercial) or groups them under the account holder’s keychain (residential) — the server chooses that from the community’s property type, so nobody can misattribute an open by passing the wrong option. Dates are calendar days in the community’s own timezone, and the response echoes the exact window it used, so a request wider than the 14-day limit is visibly trimmed rather than silently changed.
What you need to do: Nothing, unless you want it. Existing endpoints are unchanged, and a new key_usage capability appears on /v1/me. The community’s Access Log History setting must be on. Reach for the access log when you want to sync events incrementally, and this when you want reporting that matches what the community manager sees.
Who this affects: Customers (developers and integrators), and the Community Managers whose billing, occupancy, and audit reporting they automate.
Member Search and Paging
What changed: Integrations can now request one page of a community’s member list at a time, choose whether they want accepted, pending, or removed members, search by name or phone number, and read a single member directly instead of downloading the whole roster.
Where to find it: GET /v1/community/members/page and GET /v1/community/members/{account_community_id} (API reference → Community · Reads).
What you’ll see: Smaller, faster responses, a total count for building “N of M” displays, and phone-number search that tolerates any punctuation — 555-1234 finds +1 555-123-4567. Searching filters before paging, so paging through a search never skips anyone. Asking for a member who belongs to another community returns a plain “not found”, the same as an id that doesn’t exist.
What you need to do: No action needed — the existing member listing is unchanged. Switch to the paged endpoint if you poll a large community; it moves far less data, and far fewer phone numbers, per call.
Who this affects: Community Managers with API access, and their integrators.
Read Back What You’ve Broadcast
What changed: The API can now list the community messages it has already sent, not just send new ones. Until now an integration could send a broadcast but never confirm what went out.
Where to find it: GET /v1/community/messages, alongside the existing POST to the same path (API reference → Community · Writes).
What you’ll see: A newest-first, paginated history — the message text, who it was sent as, and when — with a flag telling you whether there is another page. Only real sends are listed: a test-mode key’s message is validated and discarded, so a test key can read the live history but never add to it.
What you need to do: No action needed; existing integrations are unchanged. Use it to confirm a broadcast landed, render a history, or check before re-sending after an ambiguous failure.
Who this affects: Community Managers and developers building on the Nimbio API.
Webhook Delivery History
What changed: API integrations can now pull the delivery history for any of their webhooks, so a webhook that silently stops working can be diagnosed without contacting Nimbio.
Where to find it: GET /v1/community/webhooks/{webhook_id}/deliveries (API reference → Community · Webhooks).
What you’ll see: Each recent attempt with its status — pending, delivered, or failed — how many tries it took, the HTTP status your endpoint returned, the error text if it failed, and when the next retry is due. That is enough to tell a broken receiver from an event Nimbio never fired at all. The event body itself isn’t repeated here; replay it from the live event stream if you need it.
What you need to do: No action needed — it works with your existing API key, live or test. One thing to know: the recorded error includes the beginning of your own endpoint’s response body, which is what makes a broken receiver diagnosable, so keep sensitive detail out of your error pages.
Who this affects: Community Managers and developers building on the Nimbio API.
Incremental Access-Log Sync
What changed: The two community log endpoints now accept a date range, so an integration can ask for just the rows it hasn’t seen instead of re-paging a fixed 90-day window on every poll.
Where to find it: New optional from and to query params on GET /v1/community/access-logs and GET /v1/community/gate-status-log (API reference → Community · Logs).
What you’ll see: Only the rows inside your window, with the window the server actually used echoed back in the response. Both params take either a plain date or a full timestamp, and a plain date covers the whole day. Nimbio keeps 90 days of these logs, so a start date older than that is quietly moved up to the oldest data that exists — comparing what you asked for with what came back tells you when that happened.
What you need to do: Nothing — calls that send neither param behave exactly as before. Adopt from when you want incremental sync: set it to the timestamp of the newest row you have already stored and poll from there.
Who this affects: Customers (developers and integrators)