unifi-connect

npx skills add t3chnaztea/unifi-skills --skill unifi-connect --agent claude-code

Same command for any agent — swap --agent for codex, cursor, copilot.

# UniFi Connect The first thing to know: **SSH is usually closed and you do not need it.** UniFi OS exposes a full REST API on the same host as the web UI, and everything these skills do goes through it. The second thing: **UniFi has three overlapping API surfaces with different auth rules**, and picking the wrong one produces errors that look like broken credentials when they are not. Throughout, `<UDM_HOST>` is your gateway's LAN address. Never hardcode it into a file you might share. ## Lane 1: API key (use this) API keys are the modern lane. No login round-trip, no cookie jar, no CSRF token, and they sidestep the HTTP/2 bug described below. ### Minting a key over the API The admin UI has a key page, but you do not need it. Keys are mintable from an authenticated session: ```bash # Log in once to get a session curl -sk -X POST "https://<UDM_HOST>/api/auth/login" \ -H "Content-Type: application/json" \ -d '{"username":"<ADMIN_USER>","password":"<ADMIN_PASS>"}' \ -c /tmp/unifi_cookies -D /tmp/unifi_headers CSRF=$(grep -i 'x-updated-csrf-token' /tmp/unifi_headers | awk '{print $2}' | tr -d '\r') # Mint a named key curl -sk --http1.1 -b /tmp/unifi_cookies -H "x-csrf-token: $CSRF" \

Log in once to get a session
curl -sk -X POST "https://<UDM_HOST>/api/auth/login" \
Mint a named key
curl -sk --http1.1 -b /tmp/unifi_cookies -H "x-csrf-token: $CSRF" \
curl -sk -H "X-API-Key: $UNIFI_API_KEY" \
export UNIFI_API_KEY="..."   # from an env file, never committed, never in a skill
export UDM_HOST=192.0.2.1
export UNIFI_API_KEY="..."
python3 udm.py                 # command list
python3 udm.py devices         # adopted devices