---
id: STORE-3
family: GR-STORE
level: core
profiles: [storage-api]
posture: normative-target
added: "1.0"
changed: "1.0"
source: https://flowdrop.io/spec/rules/gr-store/store-3
specification: FlowDrop Workflow Specification 1.0-draft
licence: CC BY 4.0
---

# STORE-3 — A client-supplied id never overwrites an existing workflow

*GR-STORE (Part I) · level: core · profiles: storage-api · added in 1.0*

## The rule

> **Normative.** This is the rule.
>
> 1. A create request may supply the workflow's `id`.
>
> 2. If a workflow with that id already exists, the request is refused with 409 and the stored workflow is left exactly as it was.
>
> 3. An implementation must never silently turn a create into an update.


## What it means

A caller may name the id it wants a new workflow to have, rather than being
handed one. That is a convenience with one sharp edge: an id is also how an
existing workflow is addressed, so a create request naming an id already in
use is ambiguous between "make this" and "replace that". The rule resolves
the ambiguity in one direction only — it is never an update. The incumbent
workflow is left exactly as it was, and the request that collided is refused.

## Example

The same id, sent as a create twice.

```http title="A new id" verdict="201 stored"
POST /api/flowdrop/workflows

{"id": "taken", "name": "The incumbent"}
```

```http title="The same id, claimed again" verdict="409 refused"
POST /api/flowdrop/workflows

{"id": "taken", "name": "The impostor"}
```

The second request never reaches the workflow named `taken`; the incumbent
keeps its own name.

## Related rules

- Referenced by: STORE-9

---

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.