---
title: "Get Bridge Pool Targets"
method: GET
path: "/internal/bridge/pool/targets"
tags: ["bridge pool"]
---

# Get Bridge Pool Targets

`GET /internal/bridge/pool/targets`

## 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/internal/bridge/pool/targets`
- Auth: API key in header `X-API-Key`

## Response `200`

Successful Response

- BridgePoolTargetResponse[]
  - `id` string, uuid, required: The camera's UUID (cameras.id). NOT cameras.camera_id, which is the human-readable per-site slug — this payload deliberately mirrors the ingestor camera-config contract, where `id` means the same thing.
  - `integration_id` string, uuid, required: The cloud-VMS connection that mints this device's streaming grant: GET /internal/integrations/{integration_id}/cameras/{external_device_id}/stream.
  - `external_device_id` string, required: The vendor's own camera id, used to request the grant.
  - `stream_path` string, required: The RTSP path the bridge must publish on. DERIVED FROM THE CAMERA'S STORED SOURCE URL, not recomputed from configuration, so the path the bridge publishes and the path the ingestor pulls cannot drift apart.
  - `provider` string, required: Which puller the bridge must run: `avertx` -> the OSP WebSocket puller, anything else -> the HLS URL puller. ADDED 2026-10-20 (the sixth key; the pool contract's seventh). The bridge ignores unknown keys by design, so this can ship before the bridge reads it; a bridge that does not know it keeps pulling every camera by URL, which is what every camera was before AvertX existed.
  - `monitoring_active` boolean, required: Whether this camera's schedule says it should be monitored right now, computed server-side at one shared instant for the whole response. False means the bridge must stop pulling: the stream costs ~1 Mbps and nothing downstream would look at it.
  - `shard` integer, required: The pool shard that owns this camera, 0-999, PARSED FROM THE HOST OF ITS STORED ADDRESS (bridge-pool-s{shard}.verdun.internal:8554). A shard task publishes only the rows carrying its own index; it needs no shard count and no hash.

---

[API](https://skmtc.dev/verdun/apis/verdun-api.md) - [All operations](https://skmtc.dev/verdun/apis/verdun-api/llms.txt) - [OpenAPI document](https://skmtc.dev/verdun/apis/verdun-api/revisions/35a2a6ebedda?raw)