Camera, NVR and field-phone connections

Use this guide to connect ANPR cameras, CCTV cameras, NVR channels, supported body-worn cameras and phone cameras to Sentinel ID. Choose a method the source actually supports.

Recognition and stolen/wanted alarms

Live video confirms viewing; it does not prove recognition is enabled. In Cameras > Edit > Looks for, choose Number plates for vehicle matching, Faces for enrolled people, or Plates and faces for both. Site security only skips plate and face identity matching. A readable plate must match the registered stolen/wanted vehicle; a wanted/watch-listed person needs a face enrolled through People > Profile > Add face. Declaring someone wanted does not enroll their face.

Camera cards show recognition purpose, total generated alarms and the last analysis result. recognition contains state (processed, disabled or error), checkedAt, duration and detection/match/alarm counts. lastReceivedAt distinguishes receipt from completed analysis. Failed analysis is shown separately from live video availability.

Test previews recognition without saving sightings or sending alarms. For incoming streams, leave the sample empty to use the active stream or latest received frame; an uploaded sample can also be used. Successful live matches create sightings and alarms. Users need alerts:read and access to the camera's agency to receive them. New vehicle/face match alarms include a sound; if blocked by the browser, use the speaker button in the top bar.

Photo processing applies EXIF rotation before measuring recognition coordinates. Live tiles follow decoded portrait/landscape dimensions, and the field app supports both orientations. Encoders must send upright video or valid rotation metadata: frame shape alone cannot reveal whether sideways pixels should rotate clockwise or counterclockwise.

Current test server

Setting	Current test value
Server address	http://192.168.1.31:4000
Host / port / protocol	192.168.1.31 / 4000 / HTTP
API base	http://192.168.1.31:4000/api/v1
Reachability check	GET http://192.168.1.31:4000/api/v1/health
Camera image / clip upload	POST http://192.168.1.31:4000/api/v1/cameras/ingest

These values apply to the current local test installation. The website at SentinelSecureID.com is the product website, not automatically the camera-ingestion server. For another installation, replace the origin in every example with its actual server address.

The camera or gateway must reach the server's address and configured port. localhost refers to the device making the request, so it cannot identify a different computer. For a remote site use an approved reachable HTTPS server address or routed VPN. This documentation does not open firewall ports or publish the local server to the internet.

Choose a connection method

Source	Recommended connection	Direction
ANPR camera with HTTP event snapshots	Register a push camera and POST an image using its dedicated key	Camera or gateway to server
NVR with event-image upload	Register each source/channel separately and upload its captures	NVR or gateway to server
IP camera or NVR with RTSP	Register the source RTSP URL and camera credentials	Server pulls from camera/NVR
Camera with a JPEG/PNG endpoint	Register the snapshot URL and credentials	Server pulls from source
Body-worn camera	Supported stream, exported short clip, or gateway upload, depending on the device	Depends on device support
Phone IP-camera application	Its actual snapshot or RTSP source URL, or an upload adapter	Server pulls, or adapter pushes
Sentinel ID Field	Approved device-bound user session and officer-approved sharing API	Phone uploads frames after approval

Incoming RTMP and SRT publishers are supported through the configured stream receiver, on TCP 1935 and UDP 8890 by default. Direct RTMP/RTMPS and SRT source pulling is also supported. See RTMP, RTMPS and SRT streams for authenticated publishing URLs, encoder examples, source modes, startup and encryption. Port 4000 remains the HTTP API; it is not an RTSP/RTMP/SRT publishing port.

1. Register the camera

In the admin application open Cameras > Add camera. Set its name, purpose, address and GPS, then select how images arrive. One registration represents one source/location; register NVR channels separately when their locations differ.

An integration with cameras:manage may also register the source through POST /api/v1/cameras, using Authorization: Bearer ADMIN_TOKEN and JSON. This is an authorised user token, not a camera upload key.

Example body for a push camera:

{
  "name": "Main gate ANPR",
  "mode": "push",
  "purpose": "plates",
  "address": "Main gate, inbound",
  "lat": 6.5244,
  "lng": 3.3792,
  "enabled": true
}

The response is HTTP 201 with camera, apiKey and ingestUrl. Copy the dedicated key immediately; it is shown once. The key identifies the registered camera, so do not send a different camera's location or identifier with each upload and expect it to override the registration.

2. ANPR / NVR image upload

Set the device HTTP upload method to POST and the destination to:

http://192.168.1.31:4000/api/v1/cameras/ingest

Send X-API-Key: YOUR_CAMERA_KEY. If the device cannot set request headers, use:

http://192.168.1.31:4000/api/v1/cameras/ingest?key=YOUR_CAMERA_KEY

The URL-only option still requires a POST body containing the image. A GET request or an empty alarm notification is not an image upload. Prefer the header when supported and protect any URL containing a key.

The following examples use Windows curl.exe; use curl on systems where that is the executable name.

Multipart JPEG/PNG upload:

curl.exe -X POST "http://192.168.1.31:4000/api/v1/cameras/ingest" -H "X-API-Key: YOUR_CAMERA_KEY" -F "image=@snapshot.jpg"

Raw JPEG upload:

curl.exe -X POST "http://192.168.1.31:4000/api/v1/cameras/ingest" -H "X-API-Key: YOUR_CAMERA_KEY" -H "Content-Type: image/jpeg" --data-binary "@snapshot.jpg"

Base64 JSON: save the following body in payload.json, replacing the placeholder with the actual image bytes encoded as base64. A data:image/jpeg;base64,... value is also supported.

{"image":"BASE64_IMAGE"}

curl.exe -X POST "http://192.168.1.31:4000/api/v1/cameras/ingest" -H "X-API-Key: YOUR_CAMERA_KEY" -H "Content-Type: application/json" --data-binary "@payload.json"

An image response has this shape; the values below represent an upload with no matches:

{"camera":"Main gate ANPR","plates":[],"facesMatched":0,"alerts":0}

HTTP 200 confirms processing, not a guaranteed recognition result. The dedicated camera-ingestion service does not require source-IP allow-listing. A valid camera key, enabled camera, network reachability and request limits still apply. This exception does not remove network restrictions from management APIs.

Vendor event formats and gateways

Use the vendor's HTTP image-upload action if it can send the supported body directly. Some ANPR cameras and NVRs send vendor-specific XML, multipart metadata or JSON containing only a plate number or file URL. These are not automatically interpreted as image uploads. A gateway must extract/download the permitted image and submit it in a supported format.

If the ANPR unit or gateway already supplies a plate number, use the structured-sighting endpoint with an authorised integration credential granting sightings:write:

POST http://192.168.1.31:4000/api/v1/sightings

Save the body below as sighting.json. Replace the example values with the source event's actual values.

{
  "plate": "APP-456CV",
  "cameraId": "main-gate-channel-1",
  "lat": 6.5244,
  "lng": 3.3792,
  "address": "Main gate, inbound",
  "direction": "inbound"
}

curl.exe -X POST "http://192.168.1.31:4000/api/v1/sightings" -H "X-API-Key: YOUR_INTEGRATION_KEY" -H "Content-Type: application/json" --data-binary "@sighting.json"

HTTP 201 returns sighting, vehicleKnown and alerts. This reports the supplied plate; it does not run image recognition. An optional capturedAt supplies the original event time. This is a different API contract from /cameras/ingest; management network policies and credential restrictions apply. The dedicated image-upload IP exemption does not apply to /sightings. See the API reference for image attachments and additional fields.

3. Body-camera and NVR event clips

The same camera upload endpoint accepts supported short clips as multipart or raw video:

curl.exe -X POST "http://192.168.1.31:4000/api/v1/cameras/ingest" -H "X-API-Key: YOUR_CAMERA_KEY" -F "clip=@event.mp4;type=video/mp4"

MP4, MOV, MKV, AVI, WebM, TS and 3GP inputs depend on the available decoder and actual codec. The service samples up to two frames per second, with a maximum of 60 frames per clip. The response includes clip, frames, plates, facesMatched, alerts and siteAlerts.

This endpoint processes sampled frames; it is not continuous video recording or a guarantee that the complete uploaded clip is archived as evidence. Use the appropriate recording/evidence workflow when retention of the source recording is required.

Raw image/video requests have a 100 MB route limit. Multipart uploads use the server's configured MAX_UPLOAD_MB limit and accept one file. JSON has a 60 MB request-body limit, including base64 overhead. A reverse proxy may impose a lower limit. Pace captures and handle 429 responses; a continuous stream should not be sent as an unbounded HTTP request to this endpoint.

4. RTSP camera or NVR channel

Choose Server reads the video stream. Enter the exact source URL supplied by the device or NVR, for example:

rtsp://NVR_IP:554/CHANNEL_PATH

Enter the camera's username and password in the separate fields. Source IP, port, channel path, stream profile and credentials are device-specific; the example path is a placeholder. The server needs a route to that source. A private camera behind a remote router is not reachable without appropriate routing/VPN or a gateway.

Example camera-registration body:

{
  "name": "NVR channel 1",
  "mode": "rtsp",
  "purpose": "both",
  "rtspUrl": "rtsp://NVR_IP:554/CHANNEL_PATH",
  "username": "CAMERA_USER",
  "password": "CAMERA_PASSWORD",
  "intervalSec": 5,
  "address": "Main gate"
}

Send this JSON to POST /api/v1/cameras with an authorised management token. Use the camera card's Test action to verify a frame from the actual device. RTSP stream registration does not create a push-camera upload key unless the camera is switched to push mode.

5. Snapshot or phone IP-camera application

Choose Server fetches snapshots and enter the source's actual HTTP/HTTPS image endpoint. Example registration body:

{
  "name": "Phone camera",
  "mode": "snapshot",
  "purpose": "both",
  "snapshotUrl": "http://PHONE_IP:8080/shot.jpg",
  "intervalSec": 5,
  "address": "Field location"
}

The phone-app path above is only an example. Use the URL and port displayed by the selected application, and configure authentication where supported. The server must reach the phone. A USB-only or vendor-cloud-only body camera needs an export/adapter workflow; it cannot use this endpoint merely by entering a server address.

6. Sentinel ID Field phone sharing

Use the existing approved field application for officer camera sharing. These endpoints require the phone's approved device-bound user session, not a fixed-camera upload key. Control needs devices:view.

Paths below are under http://192.168.1.31:4000/api/v1:

Method	Path	Caller / action
POST	/devices/DEVICE_ID/view	Control requests sharing; send {"audio":true} to request camera and microphone. HTTP 202 returns session status.
GET	/devices/DEVICE_ID/view	Control checks the session status.
GET	/devices/me/requests	Phone polls; request.id is the sharing session identifier.
POST	/devices/me/requests/SESSION_ID	Phone answers after officer approval with {"accept":true}; false declines.
POST	/devices/me/frame	Phone sends raw image/jpeg, up to 5 MB per frame, while sharing.
GET	/devices/DEVICE_ID/live	Authorised control viewer receives an MJPEG stream after approval.
WebSocket	/devices/DEVICE_ID/audio?token=USER_TOKEN	Authorised control viewer receives live microphone audio after camera and microphone approval.
WebSocket	/devices/me/stream?token=PHONE_TOKEN	Approved phone sends JPEG frames and microphone packets over one connection.
POST	/devices/me/audio?sessionId=SESSION_ID	Phone HTTP audio fallback; raw application/octet-stream packets for the current approved session.
POST	/devices/me/audio-state	Phone reports microphone unavailable with {"sessionId":"SESSION_ID","state":"unavailable"}.
POST	/devices/me/stop	Officer stops sharing.
DELETE	/devices/DEVICE_ID/view	Control ends the session.

DEVICE_ID means the registered Device record's _id, not the installation's deviceId string. SESSION_ID comes from request.id. Send Authorization: Bearer USER_TOKEN with the relevant user's session. The phone stops uploading when the frame response is {"continue":false}. A pending request expires after 90 seconds; a live session ends after the configured no-viewer timeout, currently 30 seconds. The officer must be able to decline or stop.

Microphone sharing requires Field app 1.5.7 or newer, explicit officer approval and Android microphone permission. Dispatch and Devices offer Enable sound / Mute sound. On the video wall, enable sound on the officer tile you want to hear. If microphone access is denied, video continues with an unavailable-audio notice. Existing video-only sessions must be ended and requested again before microphone sharing can begin. These microphone packets are live only; existing server frame recordings remain video only.

Audio packets use an 8-byte header: ASCII SSIA followed by unsigned 32-bit little-endian sample rate 16000. The payload is mono signed 16-bit little-endian PCM; packets contain up to 8192 samples (the app normally sends 2048). Invalid packets and audio outside an approved microphone session are rejected. Keep microphone and viewer traffic on secure connections in production.

Management and viewing endpoints

All paths are under the API base and require the relevant authorised Bearer token. A dedicated camera upload key does not grant management/viewer access.

Method	Path	Permission	Result
GET	/cameras?q=&page=1&limit=20	cameras:read	Search cameras in bounded pages.
POST	/cameras	cameras:manage	Register a camera. Push mode returns its key once.
PATCH	/cameras/CAMERA_ID	cameras:manage	Update source, mode, location or enabled state.
POST	/cameras/CAMERA_ID/rotate-key	cameras:manage	Issue a replacement key; the old key is revoked.
POST	/cameras/CAMERA_ID/test	cameras:manage	Test a fetched frame or uploaded multipart image; no sighting is recorded.
GET	/cameras/CAMERA_ID/snapshot.jpg	cameras:read	Latest JPEG; HTTP 204 if none is available.
GET	/cameras/CAMERA_ID/live	cameras:read	MJPEG live view, not an RTSP publishing destination.
DELETE	/cameras/CAMERA_ID	cameras:manage	Remove the registration and revoke its camera key.

A browser image tag may use ?token=USER_TOKEN on the camera live/snapshot and device live endpoints. Protect such URLs because the token grants the viewer's access. Prefer an authenticated client/header where available.

Troubleshooting and commissioning

1. From the device/gateway network, request /api/v1/health and confirm the intended server responds. This checks reachability only.
2. Register the source and test one known image with its dedicated key or authorised management test.
3. For a pulled source, check the exact URL and credentials from the server's network, then use Test.
4. Confirm the camera location, received frame and status in the admin application. Push status becomes online when frames arrive.
5. Exercise a configured lookout/site rule using approved test data, review the source image and check the response workflow.
6. Test interruptions, key revocation and disabled-camera behaviour before commissioning.

Result	Check
Connection refused / timeout	Server/source address, listening service, port, routing and firewall.
400	Missing image, unsupported/undecodable content, invalid source settings or no readable frame.
401	Missing, invalid, expired or revoked credentials.
403	Disabled camera, wrong credential type, missing permission or management network restriction.
413	Route, configured upload or reverse-proxy body limit.
429	Request rate exceeded; reduce capture rate and back off.
200 with no matches	Upload succeeded; inspect image quality, purpose, supported recognition and registered records.
204 snapshot	No frame available yet; send/fetch a valid frame first.

For installation networking see Edge and camera connectivity. For rollout planning see Camera network.