--- title: The First Idempotency Key | daily.dev description: A historical investigation into the origins of idempotency keys, tracing the concept from Birrell and Nelson's 1984 'Implementing Remote Procedure Calls' paper... canonical: https://daily.dev/posts/the-first-idempotency-key-kdsf2wgzn twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: The First Idempotency Key | daily.dev og:description: A historical investigation into the origins of idempotency keys, tracing the concept from Birrell and Nelson's 1984 'Implementing Remote Procedure Calls' paper... og:url: https://daily.dev/posts/the-first-idempotency-key-kdsf2wgzn og:image: https://api.daily.dev/og/posts/kdsf2wGzN.png og:image:alt: The First Idempotency Key og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # The First Idempotency Key **[Hacker News](https://daily.dev/sources/hn)** · 8 min read · 0 upvotes · 0 comments ## Summary A historical investigation into the origins of idempotency keys, tracing the concept from Birrell and Nelson's 1984 'Implementing Remote Procedure Calls' paper at Xerox PARC — where a 'call identifier' served to deduplicate RPC messages — through SOAP-era transport specs, Mark Nottingham's 2005 'POST Once Exactly' draft, and Stripe's popularization of the Idempotency-Key HTTP header around 2015. Along the way, the author uses analogies (a double-fed dog, Incan quipu, tally sticks) to explain exactly-once processing, and wraps up by announcing Hatchet's own idempotency key feature. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community take How the wider developer community reacted, aggregated from 2 discussions and 13 comments across hackernews, lobsters (as of 2026-08-01). **TL;DR:** Commenters appreciate the historical dig into idempotency key origins and find the Birrell/Nelson find noteworthy, but the thread quickly pivots to substantive debates about semantics inconsistency across APIs, who should own key generation, and whether natural idempotence is preferable to technical solutions. **Sentiment:** 40% positive · 40% mixed · 20% skeptical **The case for** - The discovery of Birrell/Nelson's 1984 'call identifier' as a precursor is seen as a genuinely interesting historical find. - Commenters note that practical workarounds like client-side UUIDs, UPSERTs, and PUT semantics offer accessible paths to idempotency without deep domain knowledge. - One commenter confirms the pattern was independently invented in the wild as early as 1999 for web form deduplication, validating the concept's broad utility. **The pushback** - Idempotency key semantics remain dangerously inconsistent across modern APIs 40 years later — e.g., Stripe replays even 500 responses while others only dedupe successes — and these contracts are buried in prose docs rather than machine-readable specs. - The assumption that the client should always own key generation is challenged; in transactional/escrow scenarios a server-issued signed key may be more appropriate. - Isolating idempotency to a messaging layer is argued to be misguided when other layers have the same failure modes; natural keys and occupancy rules can provide more robust end-to-end guarantees. **By community** - hackernews (mixed): Discussion is substantive and engaged, mixing genuine appreciation for the historical research with pointed critiques about API inconsistency, key ownership, and the limits of technical idempotency solutions. - lobsters (positive): Single commenter corroborates the concept's independent early invention with a personal 1999 anecdote, implicitly validating the post's historical framing. **Hottest debate:** Whether idempotency keys should be generated by the client or issued by the server, and whether technical key solutions are preferable to natural/domain-level idempotence. **Open questions** - Why haven't OpenAPI specs or client generators standardized a way to encode idempotency key semantics (retention window, deduplication scope) so middleware can act on them automatically? - Are cryptographic nonces — which prevent replays rather than enable them — truly the same underlying concept as idempotency keys, or a distinct but related idea? **Highlights** > The Birrell/Nelson call identifier find is great. One thing that still surprises me is how inconsistent idempotency key semantics are across modern APIs, forty years later. Stripe stores the first response and replays it for 24h, even if the first attempt was a 500. Some other payment APIs only dedupe successful requests, so a retry after a failure creates a brand new attempt. Same header name, very different contracts. The scary part is these details usually live in one paragraph of prose in the docs, not in the OpenAPI spec, so client generators and retry middleware have no way to know about them. I have been bitten by a provider quietly changing their key retention window in a changelog nobody read. > — [mendapi on hackernews](https://news.ycombinator.com/item?id=49134094) > Some might call this pedantic, but I think physical reality provided us the earliest idempotency keys, which were natural keys in specific systems. Some effects are idempotent because they address physical reality in a way that converges or provides mutual exclusion. The pigeon-hole principle isn't an instruction guide for birds, it just describes the reality of occupancy. An egg-tooth keeps pecking, escaping at most one egg. A dog may circle, but occupies at most one bed. The real value of idempotence is being truly end-to-end. It is about the final effect being controlled, rather than about some message hop in the middle. In my opinion, the impulse to isolate it to a messaging layer is often misguided. It presupposes that the other layers don't also have similar failure modes. It makes for a more robust system when you can elicit the desired idempotence from natural keys and occupancy rules. For example, the way REST can make creation idempotent when the name can be established ahead of the creation request, or deletion is idempotent when names are not reused. > — [saltcured on hackernews · 1 comments](https://news.ycombinator.com/item?id=49138193) > The biggest misconception here is that the client or requester is responsible for the keys. They aren’t. They can be but ideally a signed response from the service with a key is ideal. Still, a client header key is better than no key. In situations where it’s fire and forget, like payments, it’s fine to generate a deterministic key from the requesters side. In situations where transactions or escrow is in play, it’s best to request from the service so the service can orchestrate. But I’m not a CTO, just an engineer. I can’t spin bad decisions into “features” like they can. Or small novel fixes as profound advances to the industry. > — [reactordev on hackernews](https://news.ycombinator.com/item?id=49135869) > Natural idempotence requires deep understanding of the domain, which developers (and coding agents) do not always have. Also, it's still a limited solution, which doesn't solve the generic case. So it's each much easier to use technical idempotency solutions like: - stamp every initial request / domain event with the UUID (idempotency key) - use client-side IDs instead of using server-generated ones with RETURNING - use PUT instead of POST - use UPSERTs - etc. IMO, you migh as well use CQRS/ES which is a natural evolution of this idea of modeling the physical reality rather than trying to reduce it to CRUD/L. --- RE: the question of the first mentions of idempotency key. I think cryptographic nonces (number used once) are somewhat related. Idempotency keys used to easily replay messages, while nonces used in order to prevent replays. But the underlying idea is similar. > — [nivertech on hackernews](https://news.ycombinator.com/item?id=49138387) > Certainly on the web, ca. 1999 I was writing 'web apps' that generated a unique transaction ID to embed in a generated form, so that when the browser POSTed it back, the server would only action it once. Given browsers of the era liked to double POST if you accidentally clicked twice on a submit button, I'm sure I can't have been the only one doing this? > — [srtcd424 on lobsters · 2 points](https://lobste.rs/s/bu14ht/first_idempotency_key#c_uziclj) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=49083207) · 28 points · 12 comments - [lobsters](https://lobste.rs/s/bu14ht/first_idempotency_key) · 1 points · 1 comments ## Similar posts on daily.dev - [How to Stop Charging Customers Twice: A Practical Idempotency Guide](https://daily.dev/posts/how-to-stop-charging-customers-twice-a-practical-idempotency-guide-m6qetcboi) · The T-Shaped Dev · 0 upvotes · 1 comments - [Idempotency: What, Why and How](https://daily.dev/posts/idempotency-what-why-and-how-qrypjmflf) · W endell Adriel · 54 upvotes · 3 comments - [Idempotency Is Easy Until the Second Request Is Different](https://daily.dev/posts/idempotency-is-easy-until-the-second-request-is-different-skbwedvu3) · Hacker News · 0 upvotes · 0 comments - [From HTTP Retries to Kafka Redelivery: Building End-to-End Idempotency with FastAPI](https://daily.dev/posts/from-http-retries-to-kafka-redelivery-building-end-to-end-idempotency-with-fastapi-m2qkobimp) · Medium · 0 upvotes · 0 comments - [Idempotent Spring Boot: Safe REST with One Annotation](https://daily.dev/posts/idempotent-spring-boot-safe-rest-with-one-annotation-ubrhbkqcl) · Foojay.io · 12 upvotes · 0 comments --- Tags: [#architecture](https://daily.dev/tags/architecture), [#backend](https://daily.dev/tags/backend), [#distributed-systems](https://daily.dev/tags/distributed-systems) [View this post on daily.dev](https://daily.dev/posts/the-first-idempotency-key-kdsf2wgzn) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"The First Idempotency Key","url":"https://daily.dev/posts/the-first-idempotency-key-kdsf2wgzn","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/the-first-idempotency-key-kdsf2wgzn"},"datePublished":"2026-08-01T17:11:05.194Z","dateModified":"2026-08-01T21:01:52.799Z","description":"A historical investigation into the origins of idempotency keys, tracing the concept from Birrell and Nelson's 1984 'Implementing Remote Procedure Calls' paper...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/84270404a6374a784f7b5b55d5e11c30?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/84270404a6374a784f7b5b55d5e11c30?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/the-first-idempotency-key-kdsf2wgzn","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"architecture,backend,distributed-systems","timeRequired":"PT8M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"The First Idempotency Key"}]} ```