# Blink > Read Blink camera and video-doorbell state, list motion clips, and prepare guarded home-security control requests without exposing Blink credentials. - Skill: `hybridaione/blink` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add hybridaione/blink` - Raw SKILL.md: https://api.skillmd.com/api/skills/hybridaione/blink/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Security - Author: HybridAIOne (https://skillmd.com/u/hybridaione) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/hybridaione/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: ```text /secret set BLINK_EMAIL "" /secret set BLINK_PASSWORD "" ``` 3. Local console fallback: ```bash hybridclaw secret set BLINK_EMAIL "" hybridclaw secret set BLINK_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. ```bash 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: ```bash node skills/blink/blink.cjs --format json run account-login --pin "" ``` 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: ```text node skills/blink/blink.cjs [--format json|pretty] http-request [flags] node skills/blink/blink.cjs [--format json|pretty] run [flags] node skills/blink/blink.cjs [--format json|pretty] plan [flags] run account-login [--pin ] run account-refresh run devices-list http-request account-login http-request account-refresh http-request pin-verify --pin http-request devices-list http-request networks-list http-request network-status-read --network http-request sync-modules-list --network http-request cameras-list --network http-request camera-config-read --network --camera http-request camera-signals-read --network --camera http-request doorbells-list --network http-request motion-events-list --network --since 2026-05-26T00:00:00Z http-request clips-list [--network ] --since 2026-05-26T00:00:00Z --page 0 --max 50 http-request clip-download --path /api/v2/accounts//media/clip/ [--filename clip.mp4] http-request thumbnail-download --path /api/v3/media/accounts//networks////thumbnail/thumbnail.jpg?ts=&ext= [--filename camera.jpg] plan network-arm --network plan network-disarm --network plan camera-motion-set --network --camera --enable true plan camera-thumbnail-refresh --network --camera [--camera-type default|mini|doorbell] [--filename camera.jpg] plan clip-watched-mark --clip plan clip-delete --clip plan camera-live-view-start --network --camera [--camera-type default|mini|doorbell] ``` Blink clip listing uses the account-scoped `media/changed` API. `clips-list --network ` 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. When `camera-thumbnail-refresh` returns `result.failureReportContract`, follow it exactly. In particular, do not write a "possible reasons" list for a stale or failed thumbnail. Do not say the camera is offline unless the same successful live Blink response marks that exact camera offline. Do not use homescreen `app_updates`, code `105`, or an account-level app-update warning as the cause of a thumbnail failure unless the refresh or live-view request itself returned HTTP 426. Do not treat camera `status: "done"`, `updated_at`, or an unchanged thumbnail timestamp as evidence that the camera has not responded since that time. A failed thumbnail report should be limited to: camera name/id if known, command id if known, command status fields, freshness/display guidance, and the fact that no fresh image was verified. If `camera-thumbnail-refresh` returns `result.freshness.reason: "system-busy"`, say Blink returned a busy response before accepting the thumbnail command and suggest retrying later. Do not describe this as Blink server overload, rate limiting, repeated-snapshot throttling, or proof for or against a camera problem unless the same response explicitly says so. `plan` emits no live side effect. It returns `approvalText`, `approvedHelperCommandText`, the exact target host/path/method, and the bounded `httpRequest` shape. Stop after producing the plan. Only after the operator confirms that exact network/camera/clip/action through F8/F14, run the approved helper command exactly. ## Read Workflow 1. Use `devices-list` first for a compact account overview; it includes networks, sync modules, cameras, and doorbell-like devices on current Blink accounts. 2. If `devices-list` returns `blink-login-required` or fails because `BLINK_AUTH_TOKEN`, `BLINK_REFRESH_TOKEN`, `BLINK_TIER`, or `BLINK_ACCOUNT_ID` is missing or stale, run `node skills/blink/blink.cjs --format json run account-refresh` once before `account-login`. Do not tell the operator all Blink credentials are missing just because token/tier/account session secrets are not set yet. 3. If refresh cannot recover the session, run `node skills/blink/blink.cjs --format json run account-login` once. 4. If login returns `handover-required`, ask for the Blink PIN via F14. When the operator provides the PIN, run exactly `node skills/blink/blink.cjs --format json run account-login --pin `, then immediately run `node skills/blink/blink.cjs --format json run devices-list` if login succeeds. Do not read source, inspect secrets, call `http_request`, or try direct gateway/curl calls between those two helper commands. 5. If login or the PIN resume fails, report the helper error and stop. Do not guess alternate endpoints, read tokens, or retry a fresh login unless the helper explicitly returns another `handover-required`. 6. If login reports invalid credentials, app update, unsupported grant, or verification failure, stop immediately; do not try guessed API versions, OAuth password-grant, or User-Agent variants. 7. Use the narrower list commands when the operator asks for a specific network or device class; use `camera-config-read` for motion/video/illuminator settings and `camera-signals-read` for camera battery, Wi-Fi/sync signal, and temperature telemetry when the homescreen response is not enough. 8. For incident-card summaries, report concrete device ids/names, network ids, offline duration, low battery, poor signal, temperature, and motion bursts only from successful live Blink responses. ## Guarded Writes Network arm/disarm, per-camera motion detection, thumbnail snapshots, clip-state changes, deletion, and live view all affect privacy or retention. They are amber/red and require exact F8/F14 approval with the target network, camera, clip, and action in the approval text. The bounded Blink API surface used by this skill does not expose camera or sync module reboot/restart commands. Do not claim a remote reboot is available and do not probe for reboot, restart, reset, firmware, or maintenance endpoints. Do not perform destructive maintenance, account changes, password changes, notification setting changes, or firmware actions through this skill. ## References - BlinkPy: https://github.com/fronzbot/blinkpy - BlinkMonitorProtocol: https://github.com/MattTW/BlinkMonitorProtocol - Home Assistant Blink integration: https://www.home-assistant.io/integrations/blink/