Idempotency
Idempotency is the property that repeating the same request has the same effect on a server as making it once: if a client sends a call, does not get a confirmed answer, and sends the identical call again, the system ends up in the same state as if the call had been made only a single time.
Submit a project See the Odoo API integration guideReviewed by Huy Nguyen (David), CEO · Updated 28 Oct 2026 · 5 min read
This term is one of the entries in the OutsourcingVN glossary of words buyers meet while scoping a system integration that uses retries.
Why does idempotency matter?
A network call can fail after the server has already done the work but before the client receives the confirmation, which leaves the client unable to tell whether to retry or not; if a retry is not safe, the client is stuck choosing between a possible duplicate and a possible lost update. RFC 9110, the IETF standard for HTTP semantics, defines the property plainly: "A request method is considered 'idempotent' if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request." OutsourcingVN is operated by Netbase JSC, and the reason a buyer should ask about this early is that an integration which cannot retry safely either risks duplicate orders, invoices or stock movements, or has to leave a failed call unresolved rather than simply trying again.
What is an example of idempotency in practice?
An integration sends a call to create an order after a payment clears, but the connection times out before the response arrives; the client has no way to know whether the order was created. If the create-order call is idempotent, the client can safely resend the identical request: the server recognises it as the same request and returns the existing order rather than creating a second one. AWS's Builders' Library describes the same pattern with a caller-supplied identifier: "On receiving the request, the service first checks to see if it has seen this identifier before. If it has not, it starts to process the request," and requests from the same caller with the same identifier "can be considered duplicate requests."
What are the common misreadings of idempotency?
Idempotent does not mean the response body is identical on every call; RFC 9110 defines it as the same intended effect on the server's state, not a byte-identical reply, so a second response can legitimately report that the resource already exists. Idempotency is also not the same as "safe": RFC 9110 keeps safe methods, whose defined semantics are essentially read-only and request no state change, as a separate, narrower category from idempotent methods, which may change state but produce the same end state however many times they run. A lookup-before-create check and an idempotency key, the unique caller-provided client request identifier AWS prefers, are two different ways of achieving the property, not the property itself.
Plan the next step for your project
Common questions
PUT and DELETE, along with every method RFC 9110 calls safe (GET, HEAD, OPTIONS and TRACE); §9.2.2 states: "Of the request methods defined by this specification, PUT, DELETE, and safe request methods are idempotent."
Not by its method definition. RFC 9110 does not list POST among the idempotent methods, and says a client "SHOULD NOT automatically retry a request with a non-idempotent method" without some means to know it is idempotent, which is why a repeated POST, such as a payment or an order submission, needs an application-level safeguard rather than relying on the HTTP method itself.
A unique identifier the caller attaches to a request so the receiving service can recognise a retried call as a duplicate of one it already processed, as AWS's Builders' Library describes its unique caller-provided client request identifier.
Which decisions does idempotency affect?
Deciding how a retried call is recognised and handled without duplicating a record is one of the six integration parts the Odoo API integration guide assigns an owner for a custom application talking to Odoo's external API. A webhook delivery that a receiver must not apply twice is the same property applied to an inbound event rather than an outbound call. Where the question is instead a one-time move of records from one system to another rather than retrying a single call, the data migration entry covers that separately. When you know which calls in your integration would need to be retried safely, describe them and Netbase will respond through Netbase's own outsourcing-services platform; submit a project when you are ready.