[UniFi] Get one UniFi console in full, by the host id from unifi_sm_list_hosts. Returns the same shape as a list item plus the complete reportedState — hardware model and revision, firmware and controller versions, release channel, uptime, the console's UniFi applications and their versions, and its user/permission context. Use this to confirm a console is online and which applications (Network, Protect) it actually runs before calling that surface's tools against it. Pass the host id EXACTLY as returned, including its colon-delimited suffix — do not truncate it or split it on the colon.

[UniFi] List every UniFi console the API key can reach — the ENTRY POINT for this connector. A host IS a console: each item's id is the consoleId that every unifi_net_* and unifi_protect_* tool requires, so call this first. Items carry id, hardwareId, type, ipAddress, owner, isBlocked, registrationTime, lastConnectionStateChange and a reportedState block (hostname, firmware/controller versions, hardware model, and the UniFi applications installed on that console). WHAT YOU SEE DEPENDS ON THE KEY TYPE, not on permissions: a PERSONAL api.ui.com key returns only consoles owned by the person who created it, while an ORGANIZATION key returns every console in the organization — so a short list is usually a personal key rather than missing equipment. READ THE owner BOOLEAN ON EACH HOST BEFORE USING ANY unifi_net_* OR unifi_protect_* TOOL AGAINST IT: the UniFi cloud relays a request to a console only when the key's account OWNS that console, so owner true means those tools will work and owner false means every one of them returns 403 'user is not the owner of this host'. A console with owner false is still LISTED here and still looks healthy — being an admin on it, even a full admin with every application permission, does not make it relayable. Report that distinction rather than retrying: the fixes are a key from the owning account, a per-console key from that owner added in StackJack, or the direct-controller lane. Cursor-paginated: pass the response's nextToken back as nextToken for the following page.

[UniFi] List the sites across every console the API key can reach. Each item carries siteId, the owning hostId (join back to unifi_sm_list_hosts), the site's meta (name, description, timezone) and a statistics block with counts of gateways, WiFi and wired clients, offline devices, plus per-ISP WAN state. This is the ACCOUNT-WIDE site view; it is not the same thing as UniFi Network's own per-console site list, which the unifi_net_* tools use. Cursor-paginated via nextToken.

[UniFi] List UniFi devices across every reachable console, grouped by host. Each group carries hostId, hostName and a devices array whose entries include id, mac, name, model, shortname, ip, productLine, status, version, firmwareStatus, updateAvailable, isConsole, isManaged and adoptionTime. This is the INVENTORY view for reporting across an estate — it is read-only and account-wide, whereas the unifi_net_* device tools act on ONE console and can restart or adopt equipment. Filter to specific consoles with hostIds. Cursor-paginated via nextToken. NO SITE FIELD: Ubiquiti's Site Manager API does not attribute a device to a site and takes no site parameter, so this response cannot say which site a device belongs to. For a per-site device list call unifi_net_list_devices(consoleId, siteId) with the site ids from unifi_net_list_sites — one call per site.

[UniFi] Get ISP performance metrics for EVERY site on the account, at either 5-minute or 1-hour resolution. Returns per-site, per-WAN period arrays with download/upload throughput, latency, packet loss and availability. Choose the window in ONE of two ways and never both: either beginTimestamp + endTimestamp (RFC3339), or duration. duration accepts 24h with type=5m, and 7d or 30d with type=1h — a mismatched pair is rejected by UniFi. To pull metrics for particular sites instead of all of them, use unifi_sm_query_isp_metrics.

[UniFi] Get ISP metrics for a caller-chosen list of sites, each with its own time window. This is a READ that happens to use POST — the body carries the query, and nothing is changed. Supply a JSON object: {"sites":[{"hostId":"…","siteId":"…","beginTimestamp":"2026-06-30T13:35:00Z","endTimestamp":"2026-06-30T15:35:00Z"}]}. hostId and siteId are REQUIRED on every entry (get both from unifi_sm_list_sites); the timestamps are optional per entry. NORMAL, NOT FAULTS: the response can report partialSuccess when only some sites resolved, and a 502 is returned when the key has no access to a requested site — read the response rather than treating either as an outage.

[UniFi] Get one SD-WAN configuration in full, by the id from unifi_sm_list_sdwan_configs. Returns the overlay's settings plus its hubs and spokes — per-hub WAN interface and route selections, the networks each hub advertises, and the spokes attached to it. This is the INTENDED configuration; for what actually deployed to each device, call unifi_sm_get_sdwan_config_status.

[UniFi] Get the DEPLOYMENT STATUS of one SD-WAN configuration — deliberately separate from the configuration itself, because a valid configuration can still be failing to reach devices. Returns the overall generation/apply state plus per-hub and per-spoke entries with each device's own status and any error detail. This is the tool to reach for when sites on an overlay cannot see each other: compare this against unifi_sm_get_sdwan_config to tell a wrong configuration from an undeployed one.

[UniFi] List the account's SD-WAN configurations — the hub-and-spoke overlays that link sites together. Each item carries the config id, name, type, variant and timestamps. Unpaginated. Use the returned id with unifi_sm_get_sdwan_config for the full definition, or with unifi_sm_get_sdwan_config_status to see whether it actually deployed. This surface is READ-ONLY: UniFi exposes no API to create, change or delete an SD-WAN configuration.

[UniFi] ESCAPE HATCH — send an arbitrary DELETE to one UniFi console through the cloud relay. DESTRUCTIVE and generally IRREVERSIBLE: UniFi exposes no undo for a deleted object, and on the Network surface removing a device is a FACTORY RESET of that hardware, not merely an unregistration. Prefer a typed unifi_net_* or unifi_protect_* tool whenever one exists — they carry the specific warnings for each object type. The path is forwarded VERBATIM after the console id and must include its application prefix — for example "proxy/network/integration/v1/sites" or "proxy/protect/integration/v1/cameras". A bare "v1/sites" is NOT rewritten for you and returns 404. Leading slashes are tolerated. Relay limits apply: each request must complete within 25 seconds, responses over 10 MB are not returned, and each console accepts about 100 relayed requests per minute.

[UniFi] ESCAPE HATCH — send an arbitrary GET to one UniFi console through the cloud relay, for endpoints StackJack has no typed tool for. Prefer a typed unifi_net_* or unifi_protect_* tool whenever one exists: they validate arguments, clamp page sizes and describe their responses. The path is forwarded VERBATIM after the console id and must include its application prefix — for example "proxy/network/integration/v1/sites" or "proxy/protect/integration/v1/cameras". A bare "v1/sites" is NOT rewritten for you and returns 404. Leading slashes are tolerated. The console's raw response is returned unchanged. This is not marked auto-approvable even though it is a GET, because the path is caller-chosen and some UniFi GET endpoints have side effects. Relay limits apply: each request must complete within 25 seconds, responses over 10 MB are not returned, and each console accepts about 100 relayed requests per minute.

[UniFi] ESCAPE HATCH — send an arbitrary PATCH to one UniFi console through the cloud relay. DESTRUCTIVE: StackJack has no schema for the path you choose, and UniFi's PATCH semantics are not uniform — most are partial updates, but some endpoints require the FULL object and treat an omitted field as a removal. Prefer a typed unifi_net_* or unifi_protect_* tool whenever one exists. The path is forwarded VERBATIM after the console id and must include its application prefix — for example "proxy/network/integration/v1/sites" or "proxy/protect/integration/v1/cameras". A bare "v1/sites" is NOT rewritten for you and returns 404. Leading slashes are tolerated. Relay limits apply: each request must complete within 25 seconds, responses over 10 MB are not returned, and each console accepts about 100 relayed requests per minute.

[UniFi] ESCAPE HATCH — send an arbitrary POST to one UniFi console through the cloud relay. DESTRUCTIVE: StackJack has no schema for the path you choose, so it cannot tell a harmless create from a device restart, a factory reset or a policy change — the classification comes from what an arbitrary payload CAN do. Prefer a typed unifi_net_* or unifi_protect_* tool whenever one exists. The path is forwarded VERBATIM after the console id and must include its application prefix — for example "proxy/network/integration/v1/sites" or "proxy/protect/integration/v1/cameras". A bare "v1/sites" is NOT rewritten for you and returns 404. Leading slashes are tolerated. Supply the request body as a JSON object; omit it for endpoints that take none. The console's raw response is returned unchanged. Relay limits apply: each request must complete within 25 seconds, responses over 10 MB are not returned, and each console accepts about 100 relayed requests per minute.

[UniFi] ESCAPE HATCH — send an arbitrary PUT to one UniFi console through the cloud relay. DESTRUCTIVE: a PUT on UniFi replaces a whole resource, so any field you omit is cleared and any list you send replaces the stored one wholesale — an incomplete firewall or ACL list silently drops rules from enforcement. Read the current object first and send it back complete. Prefer a typed unifi_net_* or unifi_protect_* tool whenever one exists. The path is forwarded VERBATIM after the console id and must include its application prefix — for example "proxy/network/integration/v1/sites" or "proxy/protect/integration/v1/cameras". A bare "v1/sites" is NOT rewritten for you and returns 404. Leading slashes are tolerated. Relay limits apply: each request must complete within 25 seconds, responses over 10 MB are not returned, and each console accepts about 100 relayed requests per minute.

[UniFi] List the administrators of one UniFi Mobility workspace, by the workspace UUID from unifi_mob_list_workspaces. Each item carries the admin's identity and role. Worth checking before a write fails: every unifi_mob_update_* tool requires the API key's own user to appear here as an Admin, so a 403 on a write with working reads is a workspace-role problem rather than a bad key. Unpaginated.

[UniFi] List the UniFi Mobility workspaces the API key can reach — the ENTRY POINT for the Mobility surface. Each item carries the workspace UUID, its name and its role/subscription context; the UUID is required by every other unifi_mob_* tool. Unpaginated. Mobility is a SEPARATE api.ui.com surface from Network and Protect and takes no console id — it is reached directly, not relayed through a console. It is also gated by its own application permission, so if this returns 403 while the rest of the connector works, the key does not carry Mobility access and a Mobility-specific key must be added to the connector's optional Mobility API key field.

[UniFi] Get one UniFi Mobility device in full, by its workspace UUID and device UUID (both from the Mobility list tools). Returns the device's identity, connection state, LAN/DHCP configuration and wireless configuration. READ THIS FIRST before either configuration write: unifi_mob_update_device_wireless requires BOTH the SSID and the password in one call, and unifi_mob_update_device_network replaces the LAN and DHCP settings — so knowing the current values is what lets you change one thing without discarding the rest.

[UniFi] List the clients currently connected to one UniFi Mobility device. Each item carries the client's identity, addressing and connection details. Response is an envelope of {data, total, offset, limit, httpStatusCode, traceId}, paginated by limit and offset (default and maximum both 200). Useful before a wireless change: unifi_mob_update_device_wireless drops every client listed here.

[UniFi] List the devices in one UniFi Mobility workspace, by the workspace UUID from unifi_mob_list_workspaces. Each item carries the device UUID, name, model, connection state and its network and wireless configuration; the device UUID is required by every per-device Mobility tool. Response is an envelope of {data, total, offset, limit, httpStatusCode, traceId}. Paginated by limit and offset — note that UniFi's default limit is 200 and its MAXIMUM is also 200, so the default page is already the largest page available; walk further with offset.

[UniFi] Rename one UniFi Mobility device. Cosmetic: it changes the display label and nothing else — no traffic is interrupted, no client is dropped, and it is reversible by renaming again. Supply a JSON object body: {"name":"Branch Office Router"}. Returns no content on success (surfaced as ). Requires the API key's user to be an Admin of the workspace; a 403 here is a role problem, not a bad key.

[UniFi] Rewrite one UniFi Mobility device's LAN and DHCP configuration. DESTRUCTIVE: changing the gateway address or the DHCP pool re-addresses the network behind that device, so existing leases stop matching and clients lose connectivity until they renew — and setting dhcp_mode to "none" turns DHCP off entirely, after which nothing new can obtain an address. Read the current settings with unifi_mob_get_device first. Supply a JSON object body with the fields you intend to set, for example {"host_address":"192.168.10.1","dhcp_mode":"dhcp","dhcp_range_start":"192.168.10.100","dhcp_range_stop":"192.168.10.200","dhcp_lease_time":86400}, or {"dhcp_mode":"none"} to disable DHCP alone. Returns no content on success (surfaced as ). Requires the API key's user to be an Admin of the workspace.

[UniFi] Replace one UniFi Mobility device's WiFi network name and password. DESTRUCTIVE: BOTH ssid and password are required in a single call, so this always replaces the whole wireless configuration — there is no way to change one without restating the other — and applying it DROPS EVERY CURRENTLY CONNECTED CLIENT, each of which must be re-joined with the new credentials. Read the current SSID with unifi_mob_get_device and see who is connected with unifi_mob_list_device_clients before running this. Supply a JSON object body: {"ssid":"MyNetwork","password":"securepass123"}. Returns no content on success (surfaced as ). Requires the API key's user to be an Admin of the workspace.

[UniFi] Get the version of the UniFi Network application running on one console. Returns {"applicationVersion":"…"} and nothing else. Two practical uses: confirming a console actually runs UniFi Network before calling any other unifi_net_* tool against it (unifi_sm_get_host lists a console's applications, this proves the integration API answers), and checking the version when an endpoint behaves differently from the documentation. This is the only UniFi Network operation that needs no siteId.

[UniFi] List the UniFi Network sites on one console — CALL THIS SECOND, after unifi_sm_list_hosts. Almost every other unifi_net_* tool requires a siteId, and this is where it comes from. Each item carries the site id and its name. Do not confuse this with unifi_sm_list_sites: that one spans every console on the account and returns Site Manager's own richer site records, while this one is the Network application's view of a single console and returns the ids the Network API itself accepts. Offset/limit paginated with the standard 25/200 defaults.

[UniFi] List the ISO country codes and names UniFi accepts. These are the values regional and regulatory settings expect — wireless configuration in particular is country-constrained, so use this to resolve a code before writing one into a configuration body rather than guessing at the spelling. Not site-scoped. Offset/limit paginated with the standard 25/200 defaults.

[UniFi] List the device tags defined on a UniFi Network site. Tags group access points and other devices so a WiFi broadcast can be aimed at a subset of the estate instead of every radio — a broadcast configuration references tags by id, so resolve them here before writing one. Each item carries the tag id, its name and the devices carrying it.

[UniFi] List the applications UniFi's deep packet inspection can recognise, each with the DPI category it belongs to. These ids are what traffic-identification rules and application-aware policy reference, so resolve an application here before naming it in a firewall or traffic-matching configuration. Pair with unifi_net_list_dpi_categories when you want to match a whole class of traffic rather than one application. Not site-scoped.

[UniFi] List UniFi's predefined deep-packet-inspection categories — the coarse traffic classes (streaming, gaming, social, and so on) that group the individual applications returned by unifi_net_list_dpi_applications. Matching on a category covers applications added by later UniFi releases, where matching on individual application ids does not. Not site-scoped.

[UniFi] List the RADIUS authentication profiles on a UniFi Network site, with each profile's origin metadata showing whether UniFi defined it or an administrator did. Enterprise (802.1X) WiFi broadcasts and wired authentication reference a profile by id, so this is the lookup to run before configuring either. The API exposes no way to create or change a RADIUS profile — this group is read-only.

[UniFi] List the WAN interfaces defined on a UniFi Network site — the uplinks that network and NAT configuration bind to, and the ids a multi-WAN policy references. Use this to see which uplinks a site actually has before writing a configuration that names one. NOTE: this is the ONLY paginated list in the UniFi Network API with no filter parameter, so page through it with offset and limit rather than narrowing server-side.

[UniFi] List the site-to-site VPN tunnels on a UniFi Network site — the permanent links joining this site's networks to another location's. Each item carries the tunnel's identity and configuration, which is what to read when networks at two sites cannot reach each other and you need to tell a missing tunnel from a misconfigured route. READ-ONLY: the UniFi Network API exposes no tunnel create, update or delete operation.

[UniFi] List the VPN servers configured on a UniFi Network site — the remote-access endpoints clients dial into, with each server's type and configuration. Use it to confirm which VPN services a site publishes and how they are set up when troubleshooting remote access. READ-ONLY: the UniFi Network API exposes no operation to create, change or delete a VPN server, so changes must be made in the console UI.

[UniFi] Adopt a device onto a UniFi Network site, bringing it under the console's management. Additive — it takes over unmanaged hardware and removes nothing. Find the MAC address with unifi_net_list_pending_devices. BOTH arguments are required by UniFi and ignoreDeviceLimit has no default: set it false to have the adoption refused when it would exceed the console's licensed device limit (the safe choice), or true to adopt anyway and accept going over. Adoption takes a few moments to complete; confirm with unifi_net_list_devices rather than assuming the response means the device is ready.

[UniFi] Get one adopted device in full: firmware version and update state, uplink and adoption state, the features it supports, and its interfaces — the ports and radios. THE PORT LIST IS WHERE PORT INDEXES COME FROM: unifi_net_power_cycle_port takes a port index, and this read is the only place to learn which index corresponds to which physical port. Use it before any device action to confirm you have the right piece of hardware.

[UniFi] Get the most recent telemetry sample for one adopted device: uptime, transmit and receive rates, and CPU and memory utilisation. This is a SNAPSHOT of the latest values, not a time series — the UniFi Network API exposes no historical statistics endpoint, so trending means polling this and storing the results yourself. Useful for confirming a device is genuinely loaded before restarting it, and for telling a saturated uplink from an unhealthy device.

[UniFi] List the adopted UniFi devices on one Network site — access points, switches, gateways and the rest of the managed estate. Each item carries the device id used by every other device tool, its name, model, MAC, IP and state. Distinct from unifi_sm_list_devices, which is the read-only account-wide inventory across all consoles: this one is scoped to a single site and its ids are the ones the action tools accept. Offset/limit paginated with the standard 25/200 defaults.

[UniFi] List devices that a console can see but has not adopted yet — new hardware waiting to be brought under management. Each item carries the MAC address that unifi_net_adopt_device needs, plus the model and how the console discovered it. This is the tool to reach for when a newly-installed access point or switch is not appearing on a site: if it shows up here, it is reachable and simply unadopted; if it does not, the problem is upstream (power, cabling or VLAN). NOT site-scoped — adoption is a console-level concern until the device lands on a site.

[UniFi] Cut and restore PoE power on one switch port. DESTRUCTIVE in the operational sense: whatever is plugged into that port is hard-powered-off and back on with no clean shutdown — the standard remote fix for a wedged access point or camera, and equally the standard way to knock a working one offline if you name the wrong port. GET THE PORT INDEX FROM unifi_net_get_device, whose interfaces.ports list is the only mapping between index and physical port; port numbering does not necessarily match the labels printed on the chassis. Only ports actually delivering PoE respond meaningfully. Returns an empty body on success.

[UniFi] Remove a device from a UniFi Network site. DESTRUCTIVE — AND THIS IS A FACTORY RESET, NOT JUST AN UNADOPT: in Ubiquiti's own words, "if the device is online, it will be reset to factory defaults". Every setting on that device is wiped, it drops off the network, and re-adopting it afterwards gives you a blank device, not the one you had — its configuration has to be rebuilt. If the device is OFFLINE it is only removed from the console's inventory and keeps its configuration until it next comes online. Anything downstream of it (clients on that access point, devices on that switch) loses connectivity. Confirm the device with unifi_net_get_device first. Returns an empty body on success.

[UniFi] Reboot one adopted UniFi device. DESTRUCTIVE in the operational sense: the device goes offline for roughly a minute or two, and everything depending on it goes with it — clients on an access point are disconnected and must re-associate, anything behind a switch or gateway loses its link, and PoE-powered devices downstream lose power too. Configuration is preserved; this is a power cycle, not a reset. Check what is riding on the device with unifi_net_list_clients before restarting one during business hours. Returns an empty body on success; poll unifi_net_get_device to see it come back.

[UniFi] Authorize a guest client on a UniFi Network site, granting it network access without a voucher. Not destructive — it opens access rather than removing it — but note one real side effect: authorizing a client CANCELS any authorization it already has and RESETS its traffic counters, so re-running this to extend a session restarts the data allowance and the clock rather than adding to them. Check the current state with unifi_net_get_client first. Every limit is optional; omit one and the hotspot's own default applies. timeLimitMinutes bounds the session, dataUsageLimitMBytes caps total transfer, and rxRateLimitKbps/txRateLimitKbps throttle download and upload. To revoke access later use unifi_net_unauthorize_guest_access.

[UniFi] Get one connected client in full, by the client id from unifi_net_list_clients: name, IP and MAC addresses, how it is connected, and its access information — including, for a guest, whether its authorization is currently active and when it expires. Run this before authorizing or unauthorizing a guest so the action lands on the device you meant. A client that has disconnected is no longer retrievable.

[UniFi] List the clients currently connected to a UniFi Network site — wired, wireless, VPN and guest alike. Each item carries the client id the other client tools need, plus name, IP, MAC, connection type and access state. This is a view of what is connected NOW, not a history of what has been: the UniFi Network API has no past-clients endpoint, so a device that has disconnected simply will not appear. Use it to see who is on a network before changing or deleting it, and to find guests whose authorization you intend to revoke. Offset/limit paginated with the standard 25/200 defaults.

[UniFi] Revoke a guest client's network access on a UniFi Network site. DESTRUCTIVE: this does not merely mark the guest unauthorized, it DISCONNECTS the device immediately — any session in progress on it is cut. The guest must re-authenticate through the hotspot (or be re-authorized with unifi_net_authorize_guest_access) to get back on, and re-authorizing starts a fresh allowance rather than restoring the old one. Confirm you have the right device with unifi_net_get_client first: client ids are not human-readable and the wrong one throws the wrong person off the network.

[UniFi] Create a network (VLAN) on a UniFi Network site. Additive — it adds a new segment and changes no existing one. Supply the network's full configuration as a JSON object body: UniFi's network schema is polymorphic (the required fields depend on the network's purpose and type), so the reliable way to build one is to read an existing comparable network with unifi_net_get_network and adapt it. Country codes come from unifi_net_list_countries. Returns the created network including its new id.

[UniFi] Delete a network (VLAN) from a UniFi Network site. DESTRUCTIVE and irreversible: every client on that segment loses its network, and anything configured against it — WiFi broadcasts, firewall rules, policies — is left dangling. CHECK FIRST WITH unifi_net_get_network_references, which lists exactly what depends on this network. By default UniFi refuses the delete while references exist; force=true overrides that refusal and deletes anyway, which is the one setting here capable of turning a blocked mistake into a completed one. Leave force unset unless you have read the references and accepted them. Returns an empty body on success.

[UniFi] Get one network (VLAN) in full, by the id from unifi_net_list_networks — its subnet, VLAN id, DHCP settings, purpose and the rest of its configuration. unifi_net_update_network is a full replacement, not a partial update, so this response is the base document you edit and send back whole.

[UniFi] List everything that references one network — the WiFi broadcasts, firewall rules, policies and other resources that would be affected if it went away. THIS IS THE PRE-DELETE SAFETY CHECK: unifi_net_delete_network refuses by default when a network is still referenced, and its force flag exists to override exactly that refusal. Run this first, read what comes back, and only then decide whether forcing is acceptable. Returns {"referenceResources":[…]}; an empty list means nothing depends on the network.

[UniFi] List the networks (VLANs) configured on a UniFi Network site, each with the network id every other network tool needs plus its name and core settings. This is the starting point for anything involving segmentation — firewall zones, ACL rules and WiFi broadcasts all reference networks by id. Offset/limit paginated with the standard 25/200 defaults.

[UniFi] Update a network (VLAN) on a UniFi Network site. THIS IS A FULL REPLACEMENT, NOT A PATCH: the body you send becomes the network's entire configuration, and any setting you omit reverts rather than persisting. Read the current network with unifi_net_get_network, change what you need in that document, and send the whole thing back. Marked non-destructive because it edits one network in place, but be aware that changing a subnet or VLAN id can drop every client on that segment until they renew — check who is on it with unifi_net_list_clients first.

[UniFi] Create a WiFi broadcast (SSID) on a UniFi Network site. Additive — it publishes a new wireless network and leaves existing ones alone. Supply the full configuration as a JSON object body: the schema is polymorphic in its security section (open, WPA personal and enterprise each want different fields), so build it from the output of unifi_net_get_wifi_broadcast for a comparable SSID. The network it bridges to comes from unifi_net_list_networks, RADIUS profiles for enterprise security from unifi_net_list_radius_profiles, and device tags from unifi_net_list_device_tags. Returns the created broadcast including its new id.

[UniFi] Delete a WiFi broadcast (SSID) from a UniFi Network site. DESTRUCTIVE and immediately visible to end users: the SSID stops being advertised and EVERY CLIENT CURRENTLY CONNECTED TO IT IS DISCONNECTED, with no way to restore the configuration afterwards — recreating it means rebuilding the whole broadcast, and clients will need the new credentials. See who is on it with unifi_net_list_clients first, and check what else depends on the underlying network with unifi_net_get_network_references. By default UniFi refuses the delete while other resources reference the broadcast; force=true overrides that refusal. Leave force unset unless you have read those references. Returns an empty body on success.

[UniFi] Get one WiFi broadcast (SSID) in full, by the id from unifi_net_list_wifi_broadcasts — its security settings, the bands it uses, the network it bridges to, hotspot configuration and which device tags it is aimed at. unifi_net_update_wifi_broadcast is a full replacement, so this response is the document you edit and send back.

[UniFi] List the WiFi broadcasts (SSIDs) on a UniFi Network site, each with the broadcast id the other WiFi tools need, its name, and whether it is enabled. This is what to read when asked which wireless networks a site publishes, or to find the id of an SSID before changing or removing it. Offset/limit paginated with the standard 25/200 defaults.

[UniFi] Update a WiFi broadcast (SSID) on a UniFi Network site. THIS IS A FULL REPLACEMENT, NOT A PATCH: the body becomes the SSID's entire configuration and anything omitted reverts. Read the current broadcast with unifi_net_get_wifi_broadcast, edit that document, and send it whole. Marked non-destructive because it edits one SSID in place, but changing the name or the passphrase forces every currently-connected client to re-join with the new credentials — check unifi_net_list_clients before doing it during business hours.

[UniFi] Generate hotspot vouchers on a UniFi Network site. Additive — it creates new guest codes and changes nothing that already exists. Supply a JSON object body. REQUIRED: name (the note stamped on every voucher generated in this call) and timeLimitMinutes (how long access lasts from the moment the FIRST guest redeems it — later guests sharing the voucher inherit that same expiry, they do not each get a fresh window). OPTIONAL: count (1-1000, default 1), authorizedGuestLimit (how many different guests may share one voucher), dataUsageLimitMBytes (1-1048576), rxRateLimitKbps and txRateLimitKbps (2-100000 each). Example: {"name":"Lobby guests","timeLimitMinutes":1440,"count":25,"dataUsageLimitMBytes":2048}. Read the generated codes back with unifi_net_list_vouchers.

[UniFi] Delete ONE hotspot voucher by id. DESTRUCTIVE and irreversible: the code stops working immediately and any guest currently relying on it loses access — UniFi offers no way to restore a deleted voucher, only to generate a new one. Confirm which voucher you are removing with unifi_net_get_voucher first. Returns {"vouchersDeleted":1} rather than an empty body. To remove many at once use unifi_net_delete_vouchers_by_filter, but read its warning first.

[UniFi] Bulk-delete hotspot vouchers matching a filter expression. THIS IS THE MOST DANGEROUS OPERATION IN THE UNIFI CONNECTOR — read all four warnings before calling it. (1) The filter is REQUIRED and is sent to UniFi as written, with only a literal '&' or '#' transport-encoded so the query cannot be truncated into a BROADER filter, so it deletes precisely what it matches, including when that is more than you meant. (2) UniFi does NOT publicly document the filter grammar, so an expression that looks restrictive may not be — a filter that matches everything wipes every voucher on the site. (3) The response is only {"vouchersDeleted":<count>} — there is NO per-voucher audit trail, so afterwards you cannot tell which codes were destroyed. (4) There is no undo; deleted codes stop working immediately for any guest using them. ALWAYS call unifi_net_list_vouchers with the SAME filter first and read the result — that list is the only preview you get. To remove a single known voucher use unifi_net_delete_voucher instead.

[UniFi] Get one hotspot voucher in full, by the voucher id from unifi_net_list_vouchers. THIS READ RETURNS A WORKING WIFI ACCESS CODE — the voucher's code grants guest network access to anyone who has it, which is why this read is Pro-tier despite changing nothing. Returns the code alongside the voucher's name, creation and expiry times, time limit, permitted and used guest counts, and any data-usage or rate limits. Use it to confirm a specific voucher's remaining validity before reissuing one.

[UniFi] List hotspot vouchers on a UniFi Network site. THIS READ RETURNS WORKING WIFI ACCESS CODES: each voucher's code grants guest network access to whoever holds it, which is why this read is Pro-tier despite changing nothing — treat the output as credentials, not inventory. Each item carries id, code, name, createdAt, expiresAt, timeLimitMinutes, authorizedGuestLimit/authorizedGuestCount, the optional data and rate limits, and its activation state. PAGING IS DIFFERENT HERE: limit defaults to 100 and its maximum is 1000, where every other UniFi Network list is 25/200 — so a busy hotspot really can be read in one page. Run this with the same filter you intend to pass to unifi_net_delete_vouchers_by_filter BEFORE deleting, since that operation reports only a count.

[UniFi] Create a firewall policy on a UniFi Network site. Additive — it adds a rule and rewrites none. Supply the policy as a JSON object body; the schema is polymorphic in its action and match sections, so build it from unifi_net_get_firewall_policy output for a comparable existing policy. Zone ids come from unifi_net_list_firewall_zones and any port or address lists from unifi_net_list_traffic_matching_lists. IMPORTANT: creating a policy does not decide where it sits in the evaluation order — check the resulting position with unifi_net_get_firewall_policy_ordering, and change it with unifi_net_reorder_firewall_policies if it matters. Returns the created policy including its new id.

[UniFi] Create a custom firewall zone on a UniFi Network site — a new trust grouping that policies can be written between. Additive: it adds a zone and changes no existing one. Supply a JSON object body naming the zone and the networks it contains; network ids come from unifi_net_list_networks. A zone with no policies written for it does not itself change how traffic flows — creating the zone and writing the policies are two steps. Returns the created zone including its new id.

[UniFi] Delete a firewall policy from a UniFi Network site. DESTRUCTIVE and irreversible — and note which direction the risk runs: removing a rule that was BLOCKING traffic opens that traffic up, silently and immediately, with no record of what the rule contained. Read the policy with unifi_net_get_firewall_policy first and keep a copy if you may need to recreate it. If you only want to stop a rule applying for now, unifi_net_patch_firewall_policy with {"enabled":false} is reversible and this is not. Removing a policy also changes the evaluation order for its zone pair. Returns an empty body on success.

[UniFi] Delete a custom firewall zone from a UniFi Network site. DESTRUCTIVE and irreversible: every policy written between this zone and another loses its meaning, so traffic that was governed by those policies is now governed by whatever remains — which in practice means segmentation you believed was in place may no longer be. Check what the zone contains with unifi_net_get_firewall_zone and which policies reference it with unifi_net_list_firewall_policies before deleting. Only user-defined zones can be deleted; UniFi refuses a system-defined one. Returns an empty body on success.

[UniFi] Get one firewall policy in full, by the id from unifi_net_list_firewall_policies — its action, source and destination zones, the traffic it matches (including any traffic-matching lists it references) and its schedule. Read this before changing a policy: unifi_net_update_firewall_policy is a full replacement, so this document is your starting point, while unifi_net_patch_firewall_policy can change one field without it. metadata.origin tells you whether the policy is user-defined; system-defined policies cannot be modified.

[UniFi] Get the evaluation order of user-defined firewall policies FOR ONE SOURCE/DESTINATION ZONE PAIR. Both zone ids are required — UniFi keeps a separate ordering per pair, so there is no site-wide firewall order to ask for (that is ACL rules, via unifi_net_get_acl_rule_ordering). Order decides which policy wins when several match, so this is the read that explains why traffic is being allowed or blocked when the policy list alone suggests otherwise. It is also the mandatory first step before unifi_net_reorder_firewall_policies, which replaces this whole list. Zone ids come from unifi_net_list_firewall_zones.

[UniFi] Get one firewall zone in full, by the id from unifi_net_list_firewall_zones — its name, the networks assigned to it, and its origin. Read this before editing or deleting a zone: knowing which networks a zone contains is what tells you whose traffic the change affects, and metadata.origin tells you whether UniFi will permit the change at all (system-defined zones are immutable).

[UniFi] List the firewall policies on a UniFi Network site — the rules governing which traffic may pass between zones. Each item carries the policy id the other firewall tools need, its action, the zones and traffic it matches, and metadata.origin showing whether UniFi defined it or an administrator did. Note that this list is NOT the evaluation order: policies are evaluated per zone pair in the sequence returned by unifi_net_get_firewall_policy_ordering, so read that too before reasoning about which rule wins. Offset/limit paginated with the standard 25/200 defaults.

[UniFi] List the firewall zones on a UniFi Network site — the trust groupings (internal, external, guest, and any custom ones) that policies are written between. Each item carries the zone id, its name, the networks it contains and metadata.origin showing whether it is system-defined or user-defined; only user-defined zones can be changed or deleted. These ids are what unifi_net_get_firewall_policy_ordering and unifi_net_reorder_firewall_policies require.

[UniFi] Change individual fields of a firewall policy, leaving everything else as it is. This is the ONLY partial-update operation in the entire UniFi Network API — every other write is a full replacement — so prefer it whenever you are changing one thing, such as enabling or disabling a rule or renaming it. Supply only the fields you want changed as a JSON object body, e.g. {"enabled":false}. Its accepted schema is narrower than the full policy schema: fields the patch endpoint does not recognise are rejected rather than ignored, so use unifi_net_update_firewall_policy for a structural rewrite. Only user-defined policies can be modified.

[UniFi] Replace the evaluation order of user-defined firewall policies for ONE source/destination zone pair. DESTRUCTIVE because it is a WHOLE-LIST REPLACE, not a move: the ids you send become the complete order, and ANY POLICY ID YOU LEAVE OUT SILENTLY DROPS OUT OF ENFORCEMENT for that zone pair — the rule still exists and still appears in the policy list, but it stops being applied, which is the kind of failure nobody notices until traffic that should be blocked is not. ALWAYS call unifi_net_get_firewall_policy_ordering for the SAME zone pair first and build your new order from every id it returns. The two lists are not interchangeable: beforeSystemDefinedIds are evaluated before UniFi's built-in policies and afterSystemDefinedIds after them, and both are sent even when empty. Both zone ids are required — this ordering is per zone pair, not site-wide.

[UniFi] Update a firewall policy on a UniFi Network site. THIS IS A FULL REPLACEMENT: the body becomes the policy's entire definition and any field you omit reverts rather than persisting — which on a firewall rule means an omitted match condition silently widens what the rule permits. Read the current policy with unifi_net_get_firewall_policy, edit that document, and send it whole. To change a single field without restating the rest, use unifi_net_patch_firewall_policy instead. Only user-defined policies (metadata.origin) can be modified.

[UniFi] Update a firewall zone on a UniFi Network site. THIS IS A FULL REPLACEMENT: the body becomes the zone's entire definition, so a member network omitted from the list is REMOVED from the zone — and a network that leaves a zone is immediately governed by different policies. Read the current zone with unifi_net_get_firewall_zone, edit that document, and send it whole. Only user-defined zones can be modified; UniFi rejects a write against a system-defined one (check metadata.origin).

[UniFi] Create a user-defined ACL rule on a UniFi Network site. Additive — it adds a rule and rewrites none. Supply the rule as a JSON object body; the source and destination filter schemas are polymorphic, so build it from unifi_net_get_acl_rule output for a comparable existing rule. Creating a rule does not decide where it sits in evaluation order — check the result with unifi_net_get_acl_rule_ordering and change it with unifi_net_reorder_acl_rules if position matters. Returns the created rule including its new id.

[UniFi] Delete a user-defined ACL rule from a UniFi Network site. DESTRUCTIVE and irreversible, and the risk runs in the permissive direction: deleting a rule that was DENYING traffic allows that traffic immediately, with no record of what the rule contained. Read it with unifi_net_get_acl_rule first and keep a copy if you might need to recreate it. Deleting a rule also removes it from the site-wide evaluation order. Only user-defined rules can be deleted. Returns an empty body on success.

[UniFi] Get one ACL rule in full, by the id from unifi_net_list_acl_rules — its action and its complete source and destination filters. Read this before changing a rule: unifi_net_update_acl_rule is a full replacement and there is no patch equivalent for ACL rules, so this document is the only reliable base to edit from. metadata.origin tells you whether the rule is user-defined and therefore modifiable at all.

[UniFi] Get the site-wide evaluation order of user-defined ACL rules, as an ordered list of rule ids. Unlike firewall policy ordering, which is kept separately for each source/destination zone pair, ACL ordering is ONE list covering the whole site and takes no zone arguments. Order decides which rule wins when several match, so read this to explain unexpected allow or deny behaviour. It is also the mandatory first step before unifi_net_reorder_acl_rules, which replaces this entire list.

[UniFi] List the access control list rules on a UniFi Network site — the switch- and network-level rules controlling which traffic may pass. Each item carries the rule id, its action, source and destination filters and metadata.origin (only user-defined rules can be changed). This endpoint has the richest filtering in the UniFi Network API — roughly 23 filterable properties including nested source and destination filter fields — though as everywhere the expression grammar is UniFi's and undocumented. As with firewall policies, list order is not evaluation order: see unifi_net_get_acl_rule_ordering.

[UniFi] Replace the site-wide evaluation order of user-defined ACL rules. DESTRUCTIVE because it is a WHOLE-LIST REPLACE, not a move: the ids you send become the complete order, and ANY RULE ID YOU LEAVE OUT SILENTLY DROPS OUT OF ENFORCEMENT — the rule still exists and still appears in the rule list, but it stops being applied, so traffic you believe is denied quietly starts passing. THE BLAST RADIUS IS THE WHOLE SITE: unlike firewall ordering, which is confined to one zone pair, this single list governs every user-defined ACL rule on the site. ALWAYS call unifi_net_get_acl_rule_ordering first and build your new order from every id it returns.

[UniFi] Update a user-defined ACL rule on a UniFi Network site. THIS IS A FULL REPLACEMENT and there is no patch equivalent for ACL rules: the body becomes the rule's entire definition, so an omitted filter condition silently widens what the rule matches. Read the current rule with unifi_net_get_acl_rule, edit that document, and send it whole. ONLY USER-DEFINED RULES CAN BE MODIFIED — a write against a system-defined rule (see metadata.origin) is rejected by UniFi.

[UniFi] Create a DNS policy (a local DNS record) on a UniFi Network site. Additive — it adds a record and changes no existing one. Supply a JSON object body; the required fields depend on the record type (an A record wants an address, a CNAME a target, an MX a priority), so model it on unifi_net_get_dns_policy output for an existing record of the same type. Be aware that a local record SHADOWS public DNS for clients on this site, so creating one for a name that resolves publicly redirects that traffic. Returns the created policy including its new id.

[UniFi] Delete a DNS policy (a local DNS record) from a UniFi Network site. DESTRUCTIVE and irreversible: any name that resolved only through this record stops resolving for clients on the site, which typically presents as an internal service becoming unreachable by hostname while its IP still works. If the name also exists in public DNS, deleting the local record silently redirects that traffic outside the site instead. Read the record with unifi_net_get_dns_policy first and keep a copy if you may need to recreate it. Cached answers can keep the old behaviour alive briefly after deletion. Returns an empty body on success.

[UniFi] Get one DNS policy in full, by the id from unifi_net_list_dns_policies — its record type and the complete set of fields that type carries (an MX record's priority, an SRV record's port and weight, and so on). Read this before changing a record: unifi_net_update_dns_policy is a full replacement, so this document is the base you edit.

[UniFi] List the DNS policies on a UniFi Network site — the DNS records the gateway serves locally, in the familiar A, AAAA, CNAME, MX, TXT and SRV shapes. Each item carries the policy id the other DNS tools need, its record type and its value. This is what to read when a hostname resolves differently inside a site than outside it: a local record here overrides public DNS for clients on this network. Offset/limit paginated with the standard 25/200 defaults.

[UniFi] Update a DNS policy on a UniFi Network site. THIS IS A FULL REPLACEMENT, NOT A PATCH: the body becomes the record's entire definition and anything omitted reverts. Read the current record with unifi_net_get_dns_policy, edit that document, and send it whole. Marked non-destructive because it edits one record in place, but note that DNS answers are cached by clients and resolvers, so a change here does not take effect everywhere at once — an old answer can persist for as long as its TTL.

[UniFi] Create a traffic matching list on a UniFi Network site — a reusable named set of ports or IP addresses for firewall policies to reference. Additive: a newly created list matches nothing until a policy points at it, so this operation on its own changes no traffic. Supply a JSON object body with the list's name, type and entries; model it on unifi_net_get_traffic_matching_list output for an existing list of the same type. Returns the created list including its new id, which is what you then reference from a firewall policy.

[UniFi] Delete a traffic matching list from a UniFi Network site. DESTRUCTIVE and irreversible, and the damage is indirect: LIVE FIREWALL POLICIES MAY STILL REFERENCE THIS LIST, and removing the set they match against changes what those rules do without touching the rules themselves — a policy that was blocking a set of addresses can quietly stop blocking anything. Check unifi_net_list_firewall_policies for references and read the list itself with unifi_net_get_traffic_matching_list first; recreating it later means retyping every entry and re-pointing every policy. Returns an empty body on success.

[UniFi] Get one traffic matching list in full, by the id from unifi_net_list_traffic_matching_lists — its type and every entry it contains. This is how to see what a firewall policy actually matches when the rule itself only names a list. Read it before any update: unifi_net_update_traffic_matching_list is a full replacement, so the entries you send become the entire list.

[UniFi] List the traffic matching lists on a UniFi Network site — the named sets of ports or IP addresses that firewall policies reference instead of restating the same values in every rule. Each item carries the list id, its name and its type. Read this when a firewall policy refers to a list id you need to resolve, and before editing any list: one list can be referenced by many policies, so its contents are shared state. Offset/limit paginated with the standard 25/200 defaults.

[UniFi] Update a traffic matching list on a UniFi Network site. THIS IS A FULL REPLACEMENT: the entries you send become the ENTIRE list, so adding one address means sending every existing address plus the new one — sending only the new entry deletes all the others. Read the current list with unifi_net_get_traffic_matching_list and edit that document. Remember the list is shared: every firewall policy referencing it changes behaviour the moment this succeeds, so check unifi_net_list_firewall_policies for who depends on it before narrowing a list.

[UniFi] Get one Link Aggregation Group in full, by the id from unifi_net_list_lags — its member ports, the devices they sit on, and the bond's configuration. Use it to establish exactly which physical ports belong to a bond before doing anything to them. READ-ONLY.

[UniFi] Get one MC-LAG domain in full, by the id from unifi_net_list_mc_lag_domains — its member switches and the domain's configuration. This is how to identify the partner switch in a redundant pair before planning maintenance on either. READ-ONLY.

[UniFi] Get one switch stack in full, by the id from unifi_net_list_switch_stacks — its member switches and their roles within the stack. Use it to identify which chassis is the stack leader and which are members before any device-level action, since the two are not interchangeable. READ-ONLY.

[UniFi] List the Link Aggregation Groups on a UniFi Network site — sets of switch ports bonded into one logical link for extra bandwidth or redundancy. Read this when an uplink is not delivering the throughput expected, or before touching any port that might be a LAG member: power-cycling one leg of a bond degrades it silently rather than obviously. READ-ONLY: the API exposes no LAG create, update or delete.

[UniFi] List the MC-LAG (multi-chassis link aggregation) domains on a UniFi Network site — pairs of switches presenting themselves as one to a downstream device so a single switch failure does not break the link. Read this to understand a site's high-availability switching design before maintenance: restarting one member of an MC-LAG pair is survivable, restarting both is not. READ-ONLY.

[UniFi] List the switch stacks on a UniFi Network site — groups of physical switches managed as a single logical unit. Read this before device maintenance: a stack member is not an independent switch, and restarting or removing one has consequences for the whole stack rather than just the ports on that chassis. READ-ONLY.

[UniFi] Enable RTSPS (secure RTSP) streams on one UniFi Protect camera at the requested quality levels, and return their URLs. Additive and reversible — it turns streams on without changing anything else, and unifi_protect_delete_camera_rtsps_streams turns them off again. Supply a JSON object body with exactly one field: {"qualities":["high","medium","low","package"]}. At least one entry is required and no other field is accepted. high, medium and low work on every camera; package only works where the camera's hasPackageCamera flag is true. THE RETURNED URLS ARE LIVE VIDEO CREDENTIALS — anyone holding one can watch the camera, so hand them out deliberately and revoke them when the need ends.

[UniFi] Open a talkback (two-way audio) session to one UniFi Protect camera and return the stream URL plus its audio configuration — codec, sampling rate and bits per sample. Non-destructive: it creates a session and changes no device setting, and simply not using the URL ends the matter. THE RETURNED URL SPEAKS INTO THE CUSTOMER'S PREMISES, so treat it as sensitive and hand it out deliberately. Only works on cameras whose featureFlags.hasSpeaker is true — check with unifi_protect_get_camera first, since a camera without a speaker will simply fail.

[UniFi] Remove the RTSPS stream(s) for one UniFi Protect camera at the named quality levels. DESTRUCTIVE: the URLs stop working immediately and EVERY consumer of them breaks at once — a third-party NVR recording from that stream stops recording, and a video wall or automation pointed at it goes dark. Re-enabling with unifi_protect_create_camera_rtsps_streams issues a stream again, but downstream systems have to be re-pointed and the recording gap is not recoverable. Check who is consuming the stream before running this. qualities is REQUIRED: pass a comma-separated list of high, medium, low, package. Returns no content on success (surfaced as ).

[UniFi] PERMANENTLY disable a UniFi Protect camera's microphone. THIS CANNOT BE UNDONE THROUGH ANY API. UniFi's own documentation states the action cannot be reversed unless the camera is physically factory reset — there is no re-enable endpoint, and unifi_protect_update_camera cannot turn the microphone back on. After this the camera records no audio at all, which also disables audio smart-detections (smoke alarm, glass break, siren, speaking) and any talkback that depended on the microphone. This is a privacy-compliance action, not a volume control: to merely quieten the microphone, set micVolume with unifi_protect_update_camera instead, which is fully reversible. Confirm with a human before running this. Returns the camera's post-change state.

[UniFi] Get one UniFi Protect camera in full, by the camera id from unifi_protect_list_cameras. Returns the same shape as a list entry — identity and connection state, microphone state and volume, video mode, HDR setting, on-screen-display and LED settings, the current doorbell LCD message, smart-detection settings, and the featureFlags capability block. Call this before unifi_protect_update_camera so you can see the current values; the PATCH is a genuine partial update, so anything you omit is left alone.

[UniFi] Get the existing RTSPS (secure RTSP) stream URLs for one UniFi Protect camera. Returns an object keyed by quality — high, medium, low and package — where a null value means that quality currently has no stream enabled. THESE URLS ARE LIVE VIDEO CREDENTIALS: anyone holding one can watch the camera, so treat the response as sensitive, do not paste it into shared transcripts, and revoke with unifi_protect_delete_camera_rtsps_streams when finished. That sensitivity is why this read is a paid-tier tool. The package quality only exists on cameras whose hasPackageCamera flag is true. To enable a quality that is currently null, use unifi_protect_create_camera_rtsps_streams.

[UniFi] Capture a still image from one UniFi Protect camera and return a short-lived read-only download URL (valid about three minutes) plus its content type, size and expiry — the JPEG itself is never inlined in the response. THIS EGRESSES LIVE IMAGERY FROM INSIDE THE CUSTOMER'S PREMISES, which is why it is a paid-tier tool even though it only reads: fetch the URL promptly, and do not republish it. channel: omit for the main lens, or pass "package" for the downward package lens on cameras whose hasPackageCamera flag is true. highQuality: set true to force a 1080p-or-higher capture, which only works when the camera's featureFlags.supportFullHdSnapshot is true. A 503 here means THAT CAMERA is offline or unreachable — it is not a problem with your API key or with StackJack.

[UniFi] List every UniFi Protect camera on one console — the ENTRY POINT for the Protect camera surface. Returns a bare JSON ARRAY (there is no envelope and NO pagination anywhere in UniFi Protect, so this is always the complete set). Each camera carries id, name, mac, state (CONNECTED/CONNECTING/DISCONNECTED), isMicEnabled, micVolume, videoMode, hdrType, activePatrolSlot, hasPackageCamera, osdSettings, ledSettings, lcdMessage, smartDetectSettings and a featureFlags block. READ featureFlags BEFORE calling the other camera tools — supportFullHdSnapshot gates the snapshot's highQuality option, hasSpeaker gates talkback, hasMic tells you whether the microphone tools mean anything, and hasPackageCamera gates the "package" snapshot channel and RTSPS quality. Get consoleId from unifi_sm_list_hosts.

[UniFi] Update a UniFi Protect camera's settings. A genuine PARTIAL update: send only what you want to change and everything else is left alone. Supply a JSON object body using ONLY these fields — UniFi rejects any field not listed here: name (string); osdSettings {isNameEnabled, isDateEnabled, isLogoEnabled, isDebugEnabled (booleans), overlayLocation: topLeft|topMiddle|topRight|bottomLeft|bottomMiddle|bottomRight}; ledSettings {isEnabled, welcomeLed, floodLed (booleans)}; lcdMessage (doorbells) {type: DO_NOT_DISTURB|LEAVE_PACKAGE_AT_DOOR|CUSTOM_MESSAGE|IMAGE, resetAt: unix-timestamp-or-null, text: required for CUSTOM_MESSAGE and IMAGE}; micVolume (1-100); videoMode (default|highFps|sport|slowShutter|lprReflex|lprNoneReflex — check featureFlags.videoModes first); hdrType (auto|on|off); smartDetectSettings {objectTypes: [person|vehicle|package|licensePlate|face|animal], audioTypes: [alrmSmoke|alrmCmonx|alrmSiren|alrmBabyCry|alrmSpeak|alrmBark|alrmBurglar|alrmCarHorn|alrmGlassBreak]}. Example: {"name":"Front Door","hdrType":"auto"}. Note that supplying smartDetectSettings replaces the whole list for that key, so include every type you want kept.

[UniFi] Move a pan-tilt-zoom UniFi Protect camera to a stored preset position. DESTRUCTIVE because it is NOT REVERSIBLE BY THIS API: UniFi Protect provides no way to read a camera's current pan, tilt or zoom, so once you move it there is no recorded position to move it back to — and while it is pointed at the new preset it is no longer watching whatever it was covering before, which is a real gap in coverage if the camera was the only view of that area. slot -1 is the home preset and 0 or greater selects a stored preset. THERE IS ALSO NO WAY TO LIST PRESETS OR TO ASK WHETHER A CAMERA SUPPORTS PTZ AT ALL: the API publishes neither, so slots beyond the conventional 0-4 range are guesswork, and calling this against a fixed camera or an empty slot simply errors. Confirm the camera is a PTZ model and the slot is configured before running this.

[UniFi] Start a stored patrol on a pan-tilt-zoom UniFi Protect camera, putting it into continuous motion between preset positions. DESTRUCTIVE for the same reason as moving to a preset: the camera's original position is unreadable, so stopping the patrol later leaves it wherever the sweep happened to be rather than where it started — and a patrolling camera is by definition away from most of its coverage most of the time. Patrol slots run 0-4, but THE API PUBLISHES NO LIST OF CONFIGURED PATROLS and no flag saying whether a camera supports PTZ, so the slot number is a guess and an unconfigured slot or a fixed camera simply errors. Check the camera's activePatrolSlot with unifi_protect_get_camera to see whether one is already running (null means none). Stop it with unifi_protect_stop_ptz_patrol.

[UniFi] Stop the patrol currently running on a pan-tilt-zoom UniFi Protect camera. DESTRUCTIVE despite sounding like a cancellation: the camera HALTS WHEREVER THE SWEEP HAD REACHED and stays there, so it stops covering every other position on the patrol route, and because UniFi Protect exposes no way to read or record a PTZ position there is nothing to restore it to. Restarting with unifi_protect_start_ptz_patrol resumes the sweep but does not undo the intervening blind spot. Read activePatrolSlot on unifi_protect_get_camera first — it is null when no patrol is running, in which case this call does nothing useful. Returns no content on success (surfaced as ).

[UniFi] Get one UniFi Protect siren in full, by the siren id from unifi_protect_list_sirens. Returns its identity, connection state, configured volume (1-100) and status-LED setting. Worth reading before unifi_protect_test_siren_sound so you know how loud the test will actually be in an occupied building.

[UniFi] List every UniFi Protect siren on one console. Returns a bare JSON ARRAY — UniFi Protect has no pagination anywhere, so this is always the complete set. Each siren carries its id, name, connection state, volume and LED settings. The id is what unifi_protect_play_siren, unifi_protect_stop_siren and unifi_protect_test_siren_sound need. Get consoleId from unifi_sm_list_hosts.

[UniFi] Sound a UniFi Protect siren alarm for a fixed duration. DESTRUCTIVE and physically disruptive: this produces a real, loud alarm in an occupied building, which will startle people, may trigger an evacuation, and may cause a monitoring company or the police to be called. Never run it to "check whether the tool works" — use unifi_protect_test_siren_sound for that, which is a 5-second test tone. Confirm with a human first. Optional JSON object body with exactly one field: {"duration":5|10|20|30} in seconds; omit the body entirely to let UniFi use its own default. Stop it early with unifi_protect_stop_siren. Returns no content on success (surfaced as ).

[UniFi] Silence a sounding UniFi Protect siren immediately. DESTRUCTIVE despite being a cancellation, and the reason matters: a siren that is going off may be responding to a GENUINE INTRUSION, and silencing it removes the occupants' warning and the deterrent while the event is still in progress. Establish why the siren is sounding before you quiet it — a security event should be silenced by a human who has assessed it, not by an agent tidying up an alert. This does not disarm the system; the alarm state persists and unifi_protect_disable_arm_alarm is a separate, also destructive, action. Returns no content on success (surfaced as ).

[UniFi] Sound a UniFi Protect siren for 5 seconds as a test. DESTRUCTIVE, unlike the equivalent speaker test: a siren is an alarm device, so even a 5-second burst is loud enough to startle occupants and is indistinguishable from a real alarm to anyone who hears it — schedule it, and tell the site first. Optional JSON object body with exactly one field: {"volume":1-100}; omit the body entirely to test at the siren's configured volume, which you can read with unifi_protect_get_siren. Returns no content on success (surfaced as ).

[UniFi] Update a UniFi Protect siren's settings. A genuine PARTIAL update — omitted fields are left alone — and it never makes the siren sound. Supply a JSON object body using ONLY these fields, since UniFi rejects anything else: name (string), volume (integer 1-100), ledSettings . Example: {"name":"Warehouse Siren","volume":80}. Note that lowering the volume here also quietens a real alarm, not just the test tone.

[UniFi] Create a new arm profile on a UniFi Protect console. Additive — it does not select the profile or arm anything, so nothing changes about the current security posture until unifi_protect_set_current_arm_profile points at it. ALL FIVE body fields are REQUIRED and no others are accepted: name (1-255 chars), automations (array of automation ids), schedules (array of {start, end} where each is a CRON EXPRESSION, not a clock time), recordEverything (boolean), activationDelay (milliseconds, and only these four values are legal: 0, 60000, 300000, 600000). Send empty arrays for automations or schedules if you have none — they are required to be present, not to be non-empty. Example: {"name":"Night","automations":[],"schedules":[{"start":"0 22 * * *","end":"0 6 * * *"}],"recordEverything":true,"activationDelay":60000}. Only available when the console uses the local alarm manager.

[UniFi] Permanently delete a UniFi Protect arm profile. DESTRUCTIVE and irreversible: there is no undo and no recycle bin, and the profile's automations, schedules and activation delay are gone with it — recreating it means re-entering every field by hand. Worse, sensors can be bound to a profile through their armProfileIds, and deleting the profile out from under them changes when those sensors are considered armed. Read the profile with unifi_protect_list_arm_profiles and check unifi_protect_get_nvr's armMode to be sure this is not the profile the system is currently using. Returns no content on success (surfaced as ).

[UniFi] DISARM the UniFi Protect alarm system on one console. DESTRUCTIVE and consequential: this stops the premises being guarded — armed automations no longer fire, an intrusion no longer raises an alarm, and if a breach is in progress the response is called off. It is a physical-security decision that should be made by a human who knows who is on site, not by an agent clearing an alert. This takes NO parameters beyond the console id, so there is nothing to narrow its scope: it disarms the whole console. Read the current state from unifi_protect_get_nvr's armMode block first (status is arming, armed, breach or disabled). Re-arm with unifi_protect_enable_arm_alarm. Returns no content on success (surfaced as ).

[UniFi] ARM the UniFi Protect alarm system on one console, using whichever profile is currently selected. DESTRUCTIVE because arming an occupied building is how false alarms happen: sirens sound, monitoring is notified, and people still on site trigger the very sensors they are walking past. Check who is present and confirm the selected profile with unifi_protect_get_nvr's armMode (and change it with unifi_protect_set_current_arm_profile) before running this. This takes NO parameters beyond the console id — it arms the whole console, and the profile's activationDelay is the only grace period. Disarm with unifi_protect_disable_arm_alarm. Returns no content on success (surfaced as ).

[UniFi] List the arm profiles on one UniFi Protect console — the named security postures that decide which automations run, which schedules apply, whether everything is recorded, and how long arming is delayed. Returns a bare JSON ARRAY; there is no pagination. To see which profile is CURRENTLY selected and whether the system is armed right now, read the armMode block from unifi_protect_get_nvr instead — that is where the live state lives. Only available when the console uses the local alarm manager.

[UniFi] Choose which arm profile the UniFi Protect console will use when it arms. DESTRUCTIVE because it silently redefines what "armed" means for the whole site: the newly selected profile brings its own automations, schedules, recording behaviour and activation delay, so a site that appears armed afterwards may be guarding far less than before. There is no history of the previous selection, so note it from unifi_protect_get_nvr's armMode.armProfileId before changing it. Supply a JSON object body with exactly one required field: {"armProfileId":"…"}, using an id from unifi_protect_list_arm_profiles. Only available when the console uses the local alarm manager. Returns no content on success (surfaced as ).

[UniFi] Update an existing UniFi Protect arm profile. A genuine PARTIAL update: unlike the create, no field is required, and anything you omit keeps its current value. Allowed fields, and no others: name (1-255 chars), automations (array of automation ids), schedules (array of {start, end} CRON expressions), recordEverything (boolean), activationDelay (0|60000|300000|600000 milliseconds). Note that supplying automations or schedules REPLACES that whole array rather than appending to it, so read the profile from unifi_protect_list_arm_profiles first and send the complete list you intend to keep. Editing the profile that is currently selected changes behaviour on the next arm, not immediately. Only available when the console uses the local alarm manager.

[UniFi] Get one UniFi Protect alarm hub in full, by the id from unifi_protect_list_alarm_hubs. Returns its identity, connection state and configuration. Because alarm hubs and link stations share one schema upstream, the same id also works with unifi_protect_get_link_station and returns the same record.

[UniFi] List every UniFi Protect alarm hub on one console. Returns a bare JSON ARRAY; there is no pagination. Alarm hubs and link stations share the same underlying schema in UniFi Protect — they are distinguished by a flag rather than by type — so an id you see here may also resolve through unifi_protect_get_link_station, and the two lists can overlap. Use the id with unifi_protect_trigger_alarm_hub_output to switch a connected siren, light or other actuator.

[UniFi] Switch one of a UniFi Protect alarm hub's hardwired output channels. DESTRUCTIVE because it drives REAL EQUIPMENT whose identity the API does not report: an output channel typically feeds a siren, a strobe, a maglock or another actuator, and UniFi does not tell you which — so you cannot know from here whether you are about to sound an alarm or release a door. Confirm with the site what the channel is wired to before using it. outputId is the channel, 0 or 1. Optional JSON object body with only these fields: {"enable":true|false, "delay":milliseconds, "duration":milliseconds}; omit the body entirely to send no payload at all, which is not the same request as sending . Returns no content on success (surfaced as ); a 503 means the hub is offline, which is a device problem and not an API-key problem.

[UniFi] Rename a UniFi Protect alarm hub. Cosmetic and reversible: name is the ONLY field UniFi accepts on this endpoint, so this cannot change any alarm behaviour. Supply a JSON object body: {"name":"Warehouse Hub"}. Any other field is rejected.

[UniFi] Fire the UniFi Protect alarms that an administrator has configured against a given trigger id. DESTRUCTIVE and deliberately open-ended: the trigger id is an arbitrary string chosen when the alarm was set up in the UniFi Protect UI, and THIS API GIVES NO WAY TO LIST TRIGGER IDS OR TO PREVIEW WHAT AN ID DOES. Firing one can sound sirens, switch lights and relays, start recording and notify a monitoring service — and there is no undo and no cancel. Get the exact trigger id from whoever configured the alarm, and confirm the intended effect with a human before running this. Takes no body. Returns no content on success (surfaced as ); an unrecognised trigger id answers 400 and fires nothing.

[UniFi] Drive one of a UniFi Protect relay's output channels. DESTRUCTIVE and physical: a relay output is commonly wired to a DOOR STRIKE, GATE, BARRIER OR LOCK, so this can unlock or open a real entrance — and UniFi does not report what any channel is connected to, so the relay's name is your only evidence. Confirm with the site before using it. CALLING IT WITHOUT A BODY TOGGLES the current state, which makes a bodyless call NON-IDEMPOTENT: a retry after a timeout flips it back, and you cannot tell from the response which way it ended up. Prefer stating the state explicitly. Optional JSON object body with only these fields: {"state":"on"|"off", "pulseDuration":milliseconds} — pulseDuration applies only when state is "on" and auto-releases after that long, which is the safest form for a door strike. outputId is the channel, 0 or 1. Returns no content on success (surfaced as ); a 503 means the relay is offline, not that your key is wrong.

[UniFi] Get one UniFi Protect relay in full, by the relay id from unifi_protect_list_relays. Returns its identity, connection state and LED settings. Note what it does NOT return: UniFi Protect does not report which physical circuit each output channel is wired to, so the relay's name is usually the only clue about what activating it will do.

[UniFi] List every UniFi Protect relay on one console. Returns a bare JSON ARRAY; there is no pagination. Each relay carries its id, name, connection state and LED settings. Relays are switching devices — their output channels are commonly wired to door strikes, gates, barriers or lighting — so read this before unifi_protect_activate_relay_output to at least see how the installer named each one. Get consoleId from unifi_sm_list_hosts.

[UniFi] Update a UniFi Protect relay's settings. A genuine PARTIAL update — omitted fields are left alone — and it never switches an output. Supply a JSON object body using ONLY these fields: name (string), ledSettings . Example: {"name":"Front Gate Relay"}. Naming a relay accurately is worth doing precisely because unifi_protect_activate_relay_output gives no other clue about what the relay controls.

[UniFi] Get one UniFi Protect sensor in full, by the sensor id from unifi_protect_list_sensors. Returns every settings block the sensor carries — motion and glass-break sensitivities (including the separate when-armed sensitivity), ambient-light, temperature and humidity thresholds, the smoke/CO alarm toggle, scheduleMode and armProfileIds. READ THIS BEFORE unifi_protect_update_sensor: supplying armProfileIds replaces the whole list rather than adding to it, so you need the current contents to avoid unbinding the sensor from profiles you meant to keep.

[UniFi] List every UniFi Protect sensor on one console. Returns a bare JSON ARRAY; there is no pagination. Each sensor carries its id, name, connection state and its per-capability settings blocks — motion, glass break, ambient light, temperature, humidity and smoke/carbon-monoxide alarm — plus its scheduleMode and any armProfileIds it is bound to. Not every sensor model supports every capability, which is why unifi_protect_update_sensor can answer 409 for a setting that does not apply. Get consoleId from unifi_sm_list_hosts.

[UniFi] Update a UniFi Protect sensor's settings. A genuine PARTIAL update at the top level — omitted fields are left alone — but note that any ARRAY you send replaces the existing one wholesale. Supply a JSON object body using ONLY these fields: name; motionSettings {isEnabled, sensitivity 0-100, sensitivityWhenArmed 0-100}; glassBreakSettings {isEnabled, sensitivity, sensitivityWhenArmed}; lightSettings {isEnabled, lowThreshold 1-503192, highThreshold} in Lux; temperatureSettings {isEnabled, lowThreshold -39 to 124, highThreshold} in Celsius; humiditySettings {isEnabled, lowThreshold 1-99, highThreshold} in percent; alarmSettings for smoke and carbon monoxide; scheduleMode ("always" or "when_armed"); armProfileIds (array of up to 32 profile ids — REPLACES the current list, so read unifi_protect_get_sensor first); hasCustomSensitivityWhenArmed (boolean, and the when-armed sensitivities only apply when this is true). The margin values inside each settings block are read-only and decided by the hardware. A 409 response means that specific setting is not supported by this sensor model — it is not a permissions error. Turning isEnabled off stops that capability detecting anything, which is a real coverage change even though the tool is not marked destructive.

[UniFi] Get one UniFi Protect floodlight in full, by the light id from unifi_protect_list_lights. Returns its identity, connection state, force-enabled flag, lightModeSettings (mode and enableAt) and lightDeviceSettings (PIR duration and sensitivity, LED level, status indicator). Read this before unifi_protect_update_light so you can restore the current mode afterwards.

[UniFi] List every UniFi Protect floodlight on one console. Returns a bare JSON ARRAY; there is no pagination. Each light carries its id, name, connection state, whether its main LED is currently force-enabled, its mode settings (when the light turns on and whether that only applies after dark) and its hardware settings (PIR duration and sensitivity, LED brightness, status indicator). Get consoleId from unifi_sm_list_hosts.

[UniFi] Update a UniFi Protect floodlight's settings, including switching it on or off. A genuine PARTIAL update — omitted fields are left alone — and every change here is reversible by sending the previous value. Supply a JSON object body using ONLY these fields: name; isLightForceEnabled (boolean — true forces the main LED on now, false releases it back to its mode); lightModeSettings {mode: "always"|"motion"|"off", enableAt: "fulltime"|"dark"}; lightDeviceSettings {isIndicatorEnabled, pirDuration in milliseconds, pirSensitivity 0-100, ledLevel 1-6}. Example: {"isLightForceEnabled":true}. Setting mode to "off" stops the light responding to motion at all, which removes illumination that cameras and people may be relying on after dark — reversible, but worth stating before you do it.

[UniFi] Get one UniFi Protect chime in full, by the chime id from unifi_protect_list_chimes. Returns its identity, connection state, paired doorbell cameraIds and the ringSettings for each. READ THIS BEFORE unifi_protect_update_chime: both cameraIds and ringSettings are replaced wholesale by an update, so you need the current contents to avoid unpairing a doorbell you meant to keep.

[UniFi] List every UniFi Protect chime on one console. Returns a bare JSON ARRAY; there is no pagination. Each chime carries its id, name, connection state, the cameraIds of the doorbells it is paired to, and per-camera ringSettings (ringtone, volume and repeat count). Get consoleId from unifi_sm_list_hosts.

[UniFi] Update a UniFi Protect chime's settings. Partial at the top level, but ARRAYS REPLACE: sending cameraIds or ringSettings discards whatever was there before, so read the current values with unifi_protect_get_chime and send the complete list you intend to keep — an incomplete cameraIds array silently unpairs the doorbells you left out, and that chime stops ringing for them. Supply a JSON object body using ONLY these fields: name; cameraIds (array of doorbell camera ids); ringSettings (array of {cameraId, ringtoneId, volume 0-100, repeatTimes 1-10} — all four required per entry). Example: {"name":"Kitchen Chime"}.

[UniFi] Get one UniFi Protect speaker in full, by the speaker id from unifi_protect_list_speakers. Returns its identity, connection state, playback volume, microphone volume and microphone enablement. Worth reading before unifi_protect_test_speaker_sound so you know how loud the default test will be.

[UniFi] List every UniFi Protect speaker on one console. Returns a bare JSON ARRAY; there is no pagination. Each speaker carries its id, name, connection state, playback volume, microphone volume and whether its microphone is enabled. Get consoleId from unifi_sm_list_hosts.

[UniFi] Play a short test tone on a UniFi Protect speaker. Not destructive — it changes no setting, ends on its own, and is the safe way to confirm a speaker is working and audible. It does still make an audible sound in a real room, so pick your moment. Optional JSON object body with exactly one field: {"volume":1-100}; omit the body entirely to test at the speaker's configured volume, which you can read with unifi_protect_get_speaker. Returns no content on success (surfaced as ). For sirens, use unifi_protect_test_siren_sound instead — that one IS flagged destructive, because an alarm burst is not something a building can ignore.

[UniFi] Update a UniFi Protect speaker's settings. A genuine PARTIAL update — omitted fields are left alone — and every change is reversible by sending the previous value. Supply a JSON object body using ONLY these fields: name (string), volume (0-100), micVolume (0-100), isMicEnabled (boolean). Example: {"volume":60}. Unlike the camera microphone, turning isMicEnabled off here is reversible: set it back to true whenever you like.

[UniFi] Get one UniFi Protect viewer in full, by the viewer id from unifi_protect_list_viewers. Returns its identity, connection state and the live view it is displaying (null when none is assigned). Read this before unifi_protect_update_viewer so you can put the previous live view back if you change what a screen is showing.

[UniFi] List every UniFi Protect viewer on one console — the display devices that show a live view on a monitor or video wall. Returns a bare JSON ARRAY; there is no pagination. Each viewer carries its id, name, connection state and the id of the live view it is currently displaying. Join that live view id back to unifi_protect_list_liveviews to see which cameras are actually on screen. Get consoleId from unifi_sm_list_hosts.

[UniFi] Rename a UniFi Protect viewer or change which live view it displays. A genuine PARTIAL update, and fully reversible by sending the previous value — nothing is deleted and no camera stops recording. Supply a JSON object body using ONLY these fields: name (string), liveview (a live view id from unifi_protect_list_liveviews, or null to clear the screen). Example: {"liveview":"…"}. Bear in mind this changes what a person watching that monitor can see: pointing a guard station at a different live view means the cameras it used to show are no longer being watched by anyone, even though they are all still recording. Read the current value with unifi_protect_get_viewer first.

[UniFi] Create a new UniFi Protect live view. Additive — it does not change any existing live view or viewer. UNUSUALLY FOR A CREATE, UniFi requires the FULL object including fields you would expect the server to assign: all eight of id, modelKey, name, isDefault, isGlobal, owner, layout and slots are REQUIRED, and no other field is accepted. modelKey must be the literal string "liveview"; owner is a user id from unifi_protect_list_users; layout is the slot count from 1 to 26; slots is an array where every entry needs all three of cameras (array of camera ids), cycleMode ("motion" or "time") and cycleInterval (seconds). The practical approach is to copy an existing live view from unifi_protect_get_liveview and edit it. Note that setting isDefault true makes this the live view every viewer falls back to.

[UniFi] Get one UniFi Protect live view in full, by the id from unifi_protect_list_liveviews. Returns id, modelKey, name, isDefault, isGlobal, owner, layout and the complete slots array. This response is the base document for unifi_protect_update_liveview, which requires all eight fields on every request: to change one field safely, edit it in this response and send the whole object back.

[UniFi] List every UniFi Protect live view on one console — the named camera layouts that viewer devices display. Returns a bare JSON ARRAY; there is no pagination. Each live view carries id, name, owner, isDefault, isGlobal, layout (the slot count, 1-26) and a slots array giving the cameras in each slot with its cycleMode and cycleInterval. This is also the tool to call BEFORE creating or updating a live view: those endpoints require the complete object, so an existing one is the best template.

[UniFi] Update a UniFi Protect live view. THIS IS NOT A PARTIAL UPDATE, despite being a PATCH — it is the one exception on the whole UniFi Protect surface. UniFi requires the FULL object on every call: all eight of id, modelKey ("liveview"), name, isDefault, isGlobal, owner, layout and slots, and nothing else. SENDING A SUBSET DOES NOT MERGE — it either fails validation or wipes what you omitted, so a request meant to rename a live view can silently blank its camera slots and leave every screen showing it empty. ALWAYS call unifi_protect_get_liveview first, change the one field you want in that exact response, and send the whole object back. layout is 1-26; each slots entry requires cameras, cycleMode ("motion" or "time") and cycleInterval (seconds).

[UniFi] Get one UniFi Protect key fob in full, by the fob id from unifi_protect_list_fobs. Returns its identity and connection state. There is no usage history here — the API does not report when a fob was last used or what it armed or disarmed.

[UniFi] List every UniFi Protect key fob on one console — the handheld devices people use to arm and disarm. Returns a bare JSON ARRAY; there is no pagination. Each fob carries its id, name and connection state. Useful for an inventory audit of who holds a fob, but note the limit of this API: it exposes no way to enrol a new fob, revoke a lost one, or see which fob triggered a recent arm or disarm. Losing a fob has to be handled in the UniFi Protect UI. Get consoleId from unifi_sm_list_hosts.

[UniFi] Rename a UniFi Protect key fob. Cosmetic and reversible: name is the ONLY field UniFi accepts here, so this cannot revoke a fob, change what it can arm, or affect security in any way. Supply a JSON object body: {"name":"Manager Fob"}. Any other field is rejected. Naming fobs after their holders is the only way this API lets you track who has which one.

[UniFi] Get one UniFi Protect bridge in full, by the bridge id from unifi_protect_list_bridges. Returns its identity and connection state. The API does not report which accessories are attached to a given bridge, so pairing this with the sensor and fob lists is a manual correlation.