---
id: SNAP-1
family: RT-SNAP
level: core
profiles: [runtime, editor-client]
posture: normative-target
added: "1.0"
changed: "1.0"
source: https://flowdrop.io/spec/rules/rt-snap/snap-1
specification: FlowDrop Workflow Specification 1.0-draft
licence: CC BY 4.0
---

# SNAP-1 — The snapshot API carries two casings, and acceptance is the lenient half

*RT-SNAP (Part II) · level: core · profiles: runtime, editor-client · added in 1.0*

Envelope keys are snake_case and the snapshot document inside them is camelCase, so `execution_id` and `executionId` are published by the same read one nesting level apart. Both are read by consumers; neither may be normalised toward the other.

## The rule

> **Normative.** This is the rule.
>
> 1. The snapshot API's envelope-level keys are snake_case: the save acknowledgement `{entity_id, execution_id}`, the delete acknowledgement `{message, execution_id}`, and the list row `{entity_id, execution_id, workflow_id, status, thread_id, created, changed, node_count}` in that order.
>
> 2. The snapshot document published under `data.snapshot` is the snapshot's own camelCase shape: `workflowId`, `executionId`, `nodeStates`, `initialInput`, `iterationCount`, `threadId`, `createdAt`, `updatedAt`.
>
> 3. The save door accepts either spelling in its body and normalises; a read always answers camelCase.
>
> 4. `node_count` is the number of node states in the snapshot, not a count taken from the raw stored payload.

## Related rules

- Names: SNAP-2
- Referenced by: SNAP-2

---

Rule identifiers are permanent and are never renumbered. This specification carries
no implementation status: each implementation publishes its own standing against
these rules. Licensed CC BY 4.0.