Skip to main content

Reconciliation with snapshots

Snapshots return the current state of incidents and events. They cover two jobs: verifying your own writes (read-your-write) and periodic full resyncs when a changelog consumer has drifted or fallen outside the 30-day retention window.

Endpoints​

OperationEndpoint
Current incident stateGET /v2/snapshot/incident
Current event stateGET /v2/snapshot/event

Fetch current state​

curl -s "https://api.cloudsek.com/v2/snapshot/incident?status=Open&limit=100&page=1" \
  -H "Authorization: Bearer $TOKEN"

Rows are camelCase. Two identifier rules matter:

  • On incident rows, use incidentDisplayId (XVA-...) for anything you feed into write routes or changelog lookups. On event rows, use eventId (the base64 record identifier).
  • Never use the row-level id. It is the snapshot row's own UUID, not an entity identifier, and no other API accepts it.

Notes​

  • Filter carefully. You can filter incidents by incident_display_id, status, priority (P0/P1/P2), or assignee. The assignee filter takes a numeric user ID, which no read API returns; if you only have an email, filter client-side instead.
  • Uniform values. Snapshot rows return priority in the same P0/P1/P2 form as everywhere else, and assignee as an email or null.
  • Pagination. The envelope includes current_limit alongside the usual pagination fields.

Read-your-write pattern​

After a PATCH, fetch the snapshot row for that identifier and confirm the field changed. This is the most reliable way to verify a write actually landed:

curl -s "https://api.cloudsek.com/v2/snapshot/incident?incident_display_id=XVA-24388918" \
  -H "Authorization: Bearer $TOKEN"

Next​

If you find your changelog consumer has drifted, resync from a full snapshot, then resume the Changelog lifecycle sync from the newest sortableId.