FlowDrop Workflow Specification 1.0-draft

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

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.
Rule identifiers are permanent and are never renumbered. Each implementation publishes its own standing against these rules; this specification does not.spec 1.0-draft · SNAP-1 · changed in spec 1.0