Idempotency
Idempotency prevents the same event or request from creating the same side effect more than once.
Also called: idempotent, duplicate protection
Definition
An idempotent operation can be repeated with the same request identity without creating an additional unintended side effect.
Why it matters to the business
Duplicate contacts, invoices, tickets or notifications can turn a simple integration failure into an operational cleanup problem.
How it works
The integration assigns or reads a stable request identity, records completed work and ignores or safely reconciles a repeated delivery.
Where it appears in real systems
It commonly matters when APIs retry, webhooks are delivered more than once, queues redeliver messages or users repeat an action after a timeout.
Common failure modes
- No stable identity exists.
- Duplicate checks happen after the side effect.
- Keys expire too early.
- Two workers race before completion is recorded.
Implementation considerations
- Choose the correct business identity.
- Store completion state durably where required.
- Design race-safe duplicate handling.
- Test retries explicitly.
When it is appropriate
Use idempotency when the same business event may be delivered or submitted more than once.
When it is not appropriate
Do not add unnecessary duplicate-state machinery to operations that are already naturally read-only or safely repeatable.
Relationship to BYFORCE
Integration Sprint explicitly includes idempotency where the defined workflow can receive repeated events or requests.