Blink

Blink

Use this skill for Blink camera, video doorbell, network arm-state, motion event, and clip-metadata workflows. Blink does not publish an official public API; this skill follows the bounded community API surface used by BlinkPy, BlinkMonitorProtocol, and Home Assistant. Treat endpoint behavior as best-effort and stop on the first authentication or verification failure.

Core Contract

• Build and run all Blink API calls with skills/blink/blink.cjs; do not handcraft Blink URLs, auth headers, or JSON bodies when the helper supports the operation.
• Use run for live Blink calls. The helper sends its own request objects through the gateway /api/http/request path, so the model does not reconstruct endpoint details.
• Use http-request only as dry-run JSON for inspection or fallback direct http_request execution when helper live execution is unavailable. Pass emitted httpRequest fields as structured JSON; do not stringify nested fields such as captureResponseFields or secretHeaders.
• Never call http_request against guessed Blink hosts or paths. Use only the exact structured request emitted by the helper in this turn. If the helper lacks an operation, say the skill does not support that operation instead of probing.
• For ordinary operator requests, do not read or grep skills/blink/blink.cjs to debug the helper. Trust the helper output. Source inspection is for maintainers changing this skill, not for listing devices.
• Helper operations use subject-verb names (devices-list, account-login, camera-motion-set). Legacy aliases are accepted, but prefer the canonical names shown below.
• Credentials and tokens must stay in the SecretRef-backed runtime secret store; never ask the operator to paste BLINK_PASSWORD or BLINK_AUTH_TOKEN into chat, and never include either value in prose.
• Do not run hybridclaw secret get, call /api/secret, inspect env, or use curl/ad hoc scripts to fetch Blink secrets. If the helper reports missing session secrets such as BLINK_TIER, run run account-refresh once, then run account-login if refresh cannot recover the session; email/password may already be stored.
• account-login is implemented as OAuth v2 Authorization Code + PKCE in the helper. Run node skills/blink/blink.cjs --format json run account-login; do not call old password login endpoints and do not web-search or endpoint-probe inside the user task.
• The Blink-specific implementation lives under skills/blink/; the gateway pieces this skill relies on are generic http_request primitives for nested response capture, explicit token bind-domain capture, secret-backed headers, manual redirect inspection, and response-body suppression.
• The helper owns all Blink host and path selection; arbitrary host/path passthrough is not supported.
• Clip downloads must go through the gateway artifact path; return artifact handles or metadata only, and rely on the helper-emitted suppressResponseBody: true so raw video bytes do not enter model context.
• Live-view requests are red and operator-UI-only; the helper emits suppressResponseBody: true, and RTSP/HLS/session handles must not be copied into chat even after approval.
• Stop after the first 401, invalid-credentials, or verification-required response; do not retry, poll, or fan out more Blink calls until credentials or the PIN handover are resolved.
• Stop after a 426 app update is required response or OAuth unsupported_grant_type. Do not probe alternate Blink endpoints, try new User-Agents, or attempt OAuth grant_type=password; use the helper's OAuth v2 Authorization Code + PKCE path with cookie and redirect handling outside model context.

Setup

Set the initial secrets in this order:

1. Browser admin: open the active HybridClaw admin URL ending in /admin/secrets and set BLINK_EMAIL and BLINK_PASSWORD.
2. Browser /chat or TUI fallback:

/secret set BLINK_EMAIL "<account email>"
/secret set BLINK_PASSWORD "<account password>"

3. Local console fallback:

hybridclaw secret set BLINK_EMAIL "<account email>"
hybridclaw secret set BLINK_PASSWORD "<account password>"

BLINK_DEVICE_ID and BLINK_CLIENT_NAME are not secrets. The helper generates a stable OAuth hardware id automatically; BLINK_DEVICE_ID is only an optional advanced override. BLINK_CLIENT_NAME is retained as a non-secret compatibility label and is not sent to Blink OAuth v2.

node skills/blink/blink.cjs --format json run account-login

Successful OAuth v2 login captures:

BLINK_AUTH_TOKEN, BLINK_REFRESH_TOKEN, BLINK_TIER, BLINK_ACCOUNT_ID, and BLINK_CLIENT_ID. Do not ask the operator to set these manually after login; the gateway writes them to the secret store automatically.

If Blink marks the client as unverified, it sends an email/SMS PIN. Use F14 durable handover to receive that PIN from the operator, then run the login helper with the PIN:

node skills/blink/blink.cjs --format json run account-login --pin "<code>"

The PIN can appear in helper arguments because it is a short-lived operator handover code; the password and auth token must never appear there.

Helper Commands

Use this command surface directly:

node skills/blink/blink.cjs [--format json|pretty] http-request <operation> [flags]
node skills/blink/blink.cjs [--format json|pretty] run <operation> [flags]
node skills/blink/blink.cjs [--format json|pretty] plan <operation> [flags]

run account-login [--pin <code>]
run account-refresh
run devices-list

http-request account-login
http-request account-refresh
http-request pin-verify --pin <code>
http-request devices-list
http-request networks-list
http-request network-status-read --network <network-id>
http-request sync-modules-list --network <network-id>
http-request cameras-list --network <network-id>
http-request camera-config-read --network <network-id> --camera <camera-id>
http-request camera-signals-read --network <network-id> --camera <camera-id>
http-request doorbells-list --network <network-id>
http-request motion-events-list --network <network-id> --since 2026-05-26T00:00:00Z
http-request clips-list [--network <network-id>] --since 2026-05-26T00:00:00Z --page 0 --max 50
http-request clip-download --path /api/v2/accounts/<account-id>/media/clip/<file.mp4> [--filename clip.mp4]
http-request thumbnail-download --path /api/v3/media/accounts/<account-id>/networks/<network-id>/<camera-type>/<camera-id>/thumbnail/thumbnail.jpg?ts=<ts>&ext= [--filename camera.jpg]

plan network-arm --network <network-id>
plan network-disarm --network <network-id>
plan camera-motion-set --network <network-id> --camera <camera-id> --enable true
plan camera-thumbnail-refresh --network <network-id> --camera <camera-id> [--camera-type default|mini|doorbell] [--filename camera.jpg]
plan clip-watched-mark --clip <clip-id>
plan clip-delete --clip <clip-id>
plan camera-live-view-start --network <network-id> --camera <camera-id> [--camera-type default|mini|doorbell]

Blink clip listing uses the account-scoped media/changed API. clips-list --network <id> is accepted for the issue-contract command shape, but the helper still calls the account-scoped endpoint and marks the requested network in metadata; filter returned clip metadata by that network before summarizing or choosing a clip path for clip-download. For a current still image, produce a camera-thumbnail-refresh plan and, after operator approval, run the plan's approvedHelperCommandText. Do not manually stitch together refresh, devices-list, and thumbnail-download; the approved live helper command owns that full workflow, polls Blink command status, downloads the thumbnail as a gateway artifact only after a successful command, and returns result.freshness plus result.display. Do not call the image fresh unless result.freshness.ok is true. Only display or link the image artifact when result.display.shouldDisplayArtifact is true. If result.freshness.reason is command-not-completed or command-failed, report the Blink command status fields and do not download, display, or link any thumbnail. If result.freshness.thumbnailPathChanged is false, result.freshness.sameAsPrevious is true, result.display.shouldDisplayArtifact is false, or a freshness warning is present, say Blink accepted the refresh command but returned the same thumbnail instead of calling it a fresh screenshot. Do not speculate about Wi-Fi, camera hardware, firmware, reachability, or Blink service state unless a separate live Blink response explicitly says so. Do not rewrite thumbnail paths or construct media URLs by hand; the helper routes authenticated requests and stores fresh images as artifacts instead of exposing bytes in model context.