Webhooks

Webhooks are planned for SessionShot but are not live yet. This page describes the direction honestly — today, capture status is tracked by polling the status endpoint.

Why webhooks matter

Captures are asynchronous: a request is accepted instantly, a worker renders it seconds later. Polling works well at low volume, but push notifications remove the polling loop, cut latency to the moment a result exists, and make failure handling event-driven.

Planned events

The initial event set under consideration. Names and payloads may change before launch.

capture.completed

Fired when a capture finishes and a signed result URL is available — skip polling entirely.

capture.failed

Fired when a capture stops with an error code, so your pipeline can retry or alert.

capture.processing_stale

Fired if a capture sits in processing longer than expected, surfacing worker issues early.

At a high level, payloads are expected to carry the capture ID, status, target hostname, output format, and timestamps — the same safe metadata the status endpoint returns today. Signed delivery (shared-secret signatures) is part of the plan.

What to use today: polling

The status endpoint is live and covers the same need synchronously.

terminal — poll capture status

curl "https://sessionshot.com/api/captures/CAPTURE_ID"   -H "Authorization: Bearer YOUR_API_KEY"

# poll until "status" is "completed" or "failed"

No webhook setup UI exists yet

There is nothing to configure in the dashboard today. When webhooks ship, they will be announced in the beta changelog and documented in the API reference.

In the meantime

API referencePOST /api/captures and GET /api/captures/:id, with polling examples.DocumentationQuickstart, statuses, and common errors.