The snapshot API carries two casings, and acceptance is the lenient half
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
- 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. - The snapshot document published under
data.snapshotis the snapshot's own camelCase shape:workflowId,executionId,nodeStates,initialInput,iterationCount,threadId,createdAt,updatedAt. - The save door accepts either spelling in its body and normalises; a read always answers camelCase.
node_countis the number of node states in the snapshot, not a count taken from the raw stored payload.
What it means
The same execution id is spelled two ways one nesting level apart, and neither spelling is the "wrong" one to normalise away. At the envelope level — an acknowledgement, a list row — the key is snake_case. Inside the published snapshot document itself, the same value sits under the camelCase spelling. A consumer that reads one and assumes the other is just a stylistic inconsistency will read the wrong key at the wrong level.
The save door is the one asymmetry worth naming directly: it accepts a body in either spelling, but what it hands back — like every read — is always camelCase. Leniency runs one way only.
Example
"exec_saved""exec_get"DELETE /api/flowdrop-runtime/snapshot/{execution_id}
{"success": true, "data": {"message": "Snapshot deleted", "execution_id": "exec_delete_me"}}