VEverdun
analytics

Post Camera Connection Test

"Reconnect & notify", step 1: try to open each named camera's stream now, and ask its ingestor for a fresh health sample.

One RTSP DESCRIBE per camera from the API (rtsp_probe, the NVR Test & Save probe), channels of one recorder account tried serially and stopped at the first credential that went out without being proven accepted, with secret reads, DNS and probes sharing an ~11 s budget. The answer separates "the customer's camera is unreachable" from "reachable, so the outage is ours" - the second must not turn into an e-mail to the customer.

VERDUN STAFF ONLY (require_central_staff; read_only is then refused by the global write guardrail). NARROWER than Re-check on purpose: the customer-side logins can edit a camera's RTSP address, and a probe that reports reachable vs refused for an address they chose is a port scanner pointed at our own network. Scope is the Camera Health tab's own; an id outside it is a 404. Not activity-logged: it changes no configuration.

post/analytics/camera-health/connection-test

Request

  • Base URL
    https://api.verdun.ai (the document declares no server; this is the origin it was published from)
  • URL
    https://api.verdun.ai/analytics/camera-health/connection-test
  • Auth
    HTTP bearer

Request body

camera_idsstring[] required

Camera row ids. Any id the caller cannot see on the Camera Health tab makes the whole request a 404 and nothing is probed.

Example request

{
  "camera_ids": [
    "55555555-5555-5555-5555-555555555555"
  ]
}

Response

Successful Response

tested_atstring date-time required

Server time of the test; also the re-check stamp written on the cameras.

recheck_requestedinteger required

motion_clip cameras newly asked for a health sample (same cooldown as Re-check cameras). The ingestor answers within about a minute when it can reach the camera.

Changes

No recorded changes to this operation across all 2 revisions of this API.