Idempotency
Idempotency is the property of an operation that, when executed multiple times, produces the same result as a single execution. In ERP interfaces it prevents duplicate postings on retries.
Idempotency is the property of an operation that, when executed several times with the same inputs, leaves the same state as a single execution. If an idempotent call is fired two or three times – for example because a response was lost on the network and the sender retries – only exactly one effect still results: one order, one posting, one stock change.
In the ERP context, idempotency matters above all at interfaces. As soon as a system communicates with a shop, marketplace or payment service via an API, a webhook or middleware, retries are the norm, not the exception. Without idempotency, every retry creates a new record – one sales order becomes three, one payment becomes a duplicate. Idempotency makes retries harmless and is therefore the foundation of reliable, fault-tolerant integrations.
At a glance
- Executed multiple times = same final result as executed once
- Protects against duplicate postings on retries, timeouts and duplicate webhooks
- Technically usually implemented via an idempotency key
- GET, PUT, DELETE are considered idempotent – POST usually is not
- Crucial for stable ERP-shop-marketplace integrations
How does idempotency work?
An operation is idempotent if its result does not depend on how often it was executed. "Set the stock to 40 units" is idempotent: whether the command arrives once or five times, the stock ends up at 40. "Reduce the stock by 3 units", on the other hand, is not idempotent – every repetition deducts again. Idempotency is therefore not a property that arises automatically, but something that must be deliberately established when designing an interface.
In practice, this is achieved either through the wording of the operation itself (absolute instead of relative values) or through an identifier by which the receiving system recognises calls it has already processed and ignores them a second time.
The idempotency key
The most common mechanism is an idempotency key: a unique identifier (often a UUID) that the sender assigns per business operation and includes unchanged with every retry. The receiving system stores keys it has already seen. If a call arrives with a known key, it is not executed again; instead, the stored response from the first run is returned. This keeps the effect exactly single, even though the client sent it multiple times. Payment service providers apply this technique rigorously to rule out double charges.
Idempotency vs. safety of HTTP methods
In REST APIs, some methods are idempotent by definition: GET, PUT and DELETE can be repeated any number of times without changing the state beyond the first call. POST, by contrast, is considered non-idempotent because it typically creates a new resource on each call. "Idempotent" is not the same as "safe": GET changes nothing at all, so it is safe and idempotent; DELETE changes the state but is idempotent, because a second delete yields the same final result.
Why idempotency matters in the ERP system
An ERP system is the data hub where stock, orders, invoices and payments converge. It is precisely here that duplicate processing is particularly costly: a duplicated order triggers a second pick and a second shipment, a duplicate payment posting distorts the open items, a duplicate stock receipt leads to overselling.
Networks are unreliable, and that is exactly why clients retry requests: a response fails to arrive, a timeout kicks in, a queue redelivers a message. Without idempotency you have to guess in each of these cases whether the operation has already taken effect. With idempotency the answer is clear – resending has no consequences. This makes it possible to build interfaces defensively and with automatic retries without endangering data quality.
The benefit goes beyond mere error avoidance. Idempotent interfaces can be safely triggered again if a batch run was aborted or a data migration only partly completed. A restart simply repeats the operations already processed, without doing any harm. This noticeably reduces operating effort, because in the event of a fault the team does not have to laboriously reconstruct which record has already been transferred and which has not.
Idempotency in interfaces and webhooks
Webhooks are the classic place where idempotency is indispensable. A shop or payment provider usually guarantees the delivery of an event on an "at least once" basis. This means: if no quick confirmation comes back, the event is sent again – even if it was long since processed the first time. If the ERP receives the same "order paid" event twice, it must still result in only one posting.
The usual solution: every event carries a unique ID. The receiving system logs processed IDs and discards repeats. The "upsert" principle is also widespread – a record is created or updated via a business key (e.g. the marketplace order number) instead of blindly generating a duplicate. This keeps even an order synchronised multiple times unique within the ERP.
Stock synchronisation as a practical case
Stock synchronisation shows the value of idempotency especially clearly. If the ERP transmits absolute quantities ("available: 40") instead of deltas ("−3"), every transmission is idempotent. A repeatedly sent stock value at most corrects an intermediate error, but never doubles a posting – effective protection against overselling across multiple channels.
Example
Practical example: duplicate order from the online shop
A fashion retailer runs a shop that reports every order to its ERP via webhook. On a promotion day the connection is overloaded. The ERP processes an order but takes too long to respond; the shop interprets this as a failure and sends the same event again.
Without idempotency the order lands in the ERP twice: a duplicate pick, a duplicate shipment, an annoyed customer and a manual cancellation posting. With idempotency the ERP recognises the identical order number as already processed, discards the repeat and confirms it politely. The customer receives their parcel exactly once – without anyone having to intervene.
Frequently asked questions
Related services
Questions about Idempotency in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.