Read back a stored clip probe
const url = 'http://localhost:8000/api/sessions/probe/2489E9AD-2EE2-8E00-8EC9-32D5F69181C0/';const options = {method: 'GET', headers: {Authorization: 'Bearer <token>'}};
try { const response = await fetch(url, options); const data = await response.json(); console.log(data);} catch (error) { console.error(error);}curl --request GET \ --url http://localhost:8000/api/sessions/probe/2489E9AD-2EE2-8E00-8EC9-32D5F69181C0/ \ --header 'Authorization: Bearer <token>'The companion to the POST, and the reason it exists is timing. The vision read runs on a background queue, so POST /api/sessions/probe/ answers with the pose read alone and the vision block lands on the row a few seconds later. Poll this while vision_pending is true.
vision_pending is false the moment there is nothing more coming — the block has arrived, the read failed, or the feature is switched off on this deployment. A caller cannot tell those apart and does not need to: all three mean stop polling.
Costs no quota, like the POST, and shares its rate limit.
Authorizations
Section titled “Authorizations”Parameters
Section titled “Parameters”Path Parameters
Section titled “Path Parameters”Responses
Section titled “Responses”object
object
object
Examples
The vision read has landed
{ "person_present": true, "stored": true, "vision_pending": false, "detection_ratio": 1, "frames_sampled": 24, "plane": "side", "plane_confidence": 0.9, "hip_translation": 2.1, "vertical_travel": 1.2, "camera_motion": 0.002, "vision": { "model": "deepseek-v4-flash-vision-exp", "frames": 3, "activity": "jump", "activity_confidence": 0.9, "exercise": "Countermovement Jump", "exercise_confidence": 0.8, "camera_view": "side", "usage": { "prompt_tokens": 3702, "completion_tokens": 96, "total_tokens": 3798 } }}Pose read stored, vision still coming
{ "person_present": true, "stored": true, "vision_pending": true, "detection_ratio": 1, "frames_sampled": 24, "plane": "side", "plane_confidence": 1, "hip_translation": 0.21, "camera_motion": 0.001}object
Human-readable message, or a stable machine code for the cases a client branches on. The standard envelope for 400 (validation — a field-keyed object may appear instead), 401 (missing / invalid credentials), 403 (authenticated but not permitted), and 404 (absent — cross-team records are collapsed to 404 so the API never leaks the existence of another team’s data).
Example generated
{ "detail": "example"}object
Human-readable message, or a stable machine code for the cases a client branches on. The standard envelope for 400 (validation — a field-keyed object may appear instead), 401 (missing / invalid credentials), 403 (authenticated but not permitted), and 404 (absent — cross-team records are collapsed to 404 so the API never leaks the existence of another team’s data).
Example generated
{ "detail": "example"}object
Human-readable message, or a stable machine code for the cases a client branches on. The standard envelope for 400 (validation — a field-keyed object may appear instead), 401 (missing / invalid credentials), 403 (authenticated but not permitted), and 404 (absent — cross-team records are collapsed to 404 so the API never leaks the existence of another team’s data).
Example generated
{ "detail": "example"}object
Human-readable message, or a stable machine code for the cases a client branches on. The standard envelope for 400 (validation — a field-keyed object may appear instead), 401 (missing / invalid credentials), 403 (authenticated but not permitted), and 404 (absent — cross-team records are collapsed to 404 so the API never leaks the existence of another team’s data).
Example generated
{ "detail": "example"}