Skip to main content
Every write to a subject’s identity state creates a new snapshot — an immutable, versioned record of the full envelope at that point in time. Snapshots are never modified after creation.

​
Snapshot anatomy

Each snapshot has:

​
Update flow

State changes use a two-step propose-and-apply flow:
Propose — submit RFC 6902 JSON Patch operations against the current state. The proposal is stored but not applied. You must supply the current base_snapshot_version; stale proposals are rejected with 409. Apply — execute the proposal. The platform validates, applies the patch transactionally, computes the new hash and prev_hash, and persists the snapshot. Concurrent applies are serialized — a second apply against a stale base is rejected. Only add, replace, and remove operations are supported. copy, move, and test are not.

​
Reading snapshots

The view parameter controls response size: full returns the complete envelope, header returns metadata only.

​
Verification

Pass verify=hash on any snapshot read to have the server re-compute the RFC 8785 hash and compare it against the stored value. Pass verify=chain to validate the full prev_hash chain back to the root. See Integrity Verification for details.