SECURITYATLAS✳

✳ The reference desk / In practice

Idempotency

The property that repeating the same operation has the same intended effect on state as performing it once; separate audit records may still be created.

What it means

Idempotency makes retries safer by keeping the intended effect on state unchanged when the same operation is repeated. Setting an account to disabled can be idempotent; toggling its enabled status is not, because a second call can undo the first. The response and audit record may differ between attempts even when the resource state is the same. Distributed workflows need this distinction because a timeout does not reveal whether the first request failed, succeeded, or is still processing.

See the idea / Automation

Two attempts can have one intended state effect.

Compare repeating a set-disabled operation with repeating a toggle. A lost response never reverses the service’s completed change.

Synthetic AccountDesk U91 starts enabled in each independent path. Two ordered, authorized calls use the same target and payload within that path; no other writer intervenes. The first response is lost after the service applies the request. The original B91 snapshot stays retained. Compare SET enabled=false with TOGGLE current value.

Idempotency: Compare repeating a set-disabled operation with repeating a toggle. A lost response never reverses the service’s completed change. The chapter text below describes every state.AccountDesk · two ordered attemptsSame U91 · fresh start in each pathRepeated operation · U91SET enabled = falseSame target and payload each timeService state · teaching viewEnabled · unchangedOriginal B91 retained: enabledSeparate attempt recordsNo attempts appliedEach attempt is recorded separatelyCaller’s independent readbackNot read · result unknownExisting sessions not checkedSTATE EFFECT DEPENDS ON MEANING

01 / 04

Start

U91 starts enabled. The chosen operation has a documented meaning; neither attempt nor the independent read has run.

More about this step

The set path uses PUT /accounts/U91/enabled with {"enabled":false}. The toggle path uses POST /accounts/U91/toggle with {}. Each path starts from a separate identical fixture. Permission and the stated API contract are assumed; no concurrent writer changes U91.

Keep in mindThis compares intended account state, not identical responses or exactly-once execution. Both attempts have separate records. No idempotency-key mechanism, existing-session revocation, authorization proof or whole-account containment is established. The toggle retry is a teaching counterexample, not a safe retry policy.

Read the visual, step by step

Set disabled twice

  1. Start. U91 starts enabled. The chosen operation has a documented meaning; neither attempt nor the independent read has run. The set path uses PUT /accounts/U91/enabled with {"enabled":false}. The toggle path uses POST /accounts/U91/toggle with {}. Each path starts from a separate identical fixture. Permission and the stated API contract are assumed; no concurrent writer changes U91.
  2. First attempt. The service applies the first call and disables U91. Its response is lost, so the caller still cannot conclude what happened. Attempt A91 reaches the service and changes enabled from true to false in both paths. The fixture discards the completed response. The service state shown is a teaching view, not information delivered to the caller. Retained B91 still says enabled=true.
  3. Repeat. The second identical set-disabled call leaves U91 disabled. A92 is a second execution and has its own attempt record. In this controlled contrast its response is also discarded, isolating the state effect from the final independent read. A toggle flips false to true; assigning false again leaves false. No deduplication or exactly-once delivery is claimed.
  4. Read back. An independent read returns enabled=false after both set-disabled calls. GET /accounts/U91/enabled returns HTTP 200 with {"enabled":true} in the toggle path or {"enabled":false} in the set path. The caller’s observation changes only after this read completes. Original B91 and both attempt records remain. Existing application sessions are outside this example.

Toggle twice · counterexample

  1. Start. U91 starts enabled. The chosen operation has a documented meaning; neither attempt nor the independent read has run. The set path uses PUT /accounts/U91/enabled with {"enabled":false}. The toggle path uses POST /accounts/U91/toggle with {}. Each path starts from a separate identical fixture. Permission and the stated API contract are assumed; no concurrent writer changes U91.
  2. First attempt. The service applies the first call and disables U91. Its response is lost, so the caller still cannot conclude what happened. Attempt A91 reaches the service and changes enabled from true to false in both paths. The fixture discards the completed response. The service state shown is a teaching view, not information delivered to the caller. Retained B91 still says enabled=true.
  3. Repeat. The second identical call toggles U91 back to enabled. A92 is a second execution and has its own attempt record. In this controlled contrast its response is also discarded, isolating the state effect from the final independent read. A toggle flips false to true; assigning false again leaves false. No deduplication or exactly-once delivery is claimed.
  4. Read back. An independent read returns enabled=true after the repeated toggle. GET /accounts/U91/enabled returns HTTP 200 with {"enabled":true} in the toggle path or {"enabled":false} in the set path. The caller’s observation changes only after this read completes. Original B91 and both attempt records remain. Existing application sessions are outside this example.

This compares intended account state, not identical responses or exactly-once execution. Both attempts have separate records. No idempotency-key mechanism, existing-session revocation, authorization proof or whole-account containment is established. The toggle retry is a teaching counterexample, not a safe retry policy.

Flow references: IETF RFC 9110: Idempotent Methods

AN ILLUSTRATIVE SCENARIO

A lost response and two different meanings

In two independent AccountDesk exercises, U91 starts enabled. The first response is lost after disabling it. Repeating SET enabled=false keeps it disabled; repeating TOGGLE enables it again. A later independent GET supplies the caller’s observed state. Both attempts retain separate records and the original snapshot. No concurrent writer or existing-session check is included.

Put it to work

  1. Express the desired state where possible, such as enabled equals false. Read the API contract and identify which operations can safely repeat and which need duplicate protection.
  2. For supported APIs, reuse an idempotency key for the same logical request. Define the request scope and lifetime, and handle conflicting payloads rather than silently treating them as the same action.
  3. Bound retries and verify the final resource state. Record attempts separately from the logical operation so investigators can explain a timeout, a retry, and one intended outcome.

How to check your work

In a test environment, send the same request twice and simulate a lost response. Confirm one intended state change, understandable audit records, and safe handling when the same key is mistakenly reused with different parameters.

Connect the ideas

  • Retry budget

    A limit on how often automation may repeat an action, especially when the previous outcome is uncertain.

  • Postcondition

    The independently checked state of the world that should be true after a response action.

  • SOAR

    Tooling that runs playbooks across security systems, which still needs scoped authority and verification.

  • Audit trail

    An append-oriented history of security-relevant actions that can be shown to a later reviewer.

Explore a field lesson

Find your next idea.

Tip: press / to open search. Escape closes this window.