Skip to main content

Changelog lifecycle sync

The changelog is an audit-style stream of 23 action types across incidents, events, and comments: status changes, priority changes, assignments, comments, remediations, and more. It is the backbone of any sync that needs to know what changed since it last looked.

Endpoints​

OperationEndpoint
Poll lifecycle changesGET /v2/changelog

The cursor pattern​

Every row has a sortableId. Store the highest one you have processed and pass it back as the sortable_id query parameter to resume exactly where you left off:

curl -s "https://api.cloudsek.com/v2/changelog?sortable_id=$LAST_CURSOR&sort=asc&limit=200" \
  -H "Authorization: Bearer $TOKEN"

The envelope is { "data": [...], "total": n } and rows are camelCase:

{
  "entityId": "XVA-24388918",
  "entityType": "incident",
  "actionType": "incident_status_changed",
  "moduleName": "CompromisedComputers",
  "currentState": { "status": "acknowledged" },
  "actionedAt": "1785235193051",
  "sortableId": "18042117",
  "operationId": "019fa850-09bb-7114-9ed4-bb8c88999475",
  "integration_metadata": { "operation_id": "...", "mapping_mode": "CONFIG_INTEGRATION_USER" }
}

Notes that save a debugging session​

  • Timestamp units differ between response and filter. actionedAt is epoch milliseconds as a string; the actioned_after filter takes epoch seconds as a number. Divide by 1000 before feeding a row's timestamp back in.
  • Look up incidents by Display ID. The entity_identifier parameter takes XVA-... for incidents (legacy UUIDs are deprecated) and the base64 event_record_identifier for events.
  • Skip your own echoes. Rows produced by your integration's writes carry integration_metadata and the operationId of the write. When you see your own operation IDs, do not mirror the change back to your system, or you will build a loop. See Two-way ticketing sync.
  • Normalize status labels. currentState.status uses internal labels (acknowledged, in-progress) rather than the write enum. Normalize before comparing against the statuses you write.
  • Retention is 30 days. A consumer that falls more than 30 days behind must resync from snapshots.

Next​

Pair this with Two-way ticketing sync to turn detected changes into ticket updates, and use Reconciliation as your fallback when a consumer drifts past the retention window.