# Working with the new Idempotency Keys RFC

DevFeed: [Working with the new Idempotency Keys RFC](<https://devfeed.tech/articles/working-with-the-new-idempotency-keys-rfc-19075.md>)

Original publisher: [Read original article](<https://httptoolkit.com/blog/idempotency-keys/>)

Author: HTTP Toolkit; Phil Sturgeon

Published: 2023-12-12T15:00:00Z

Content type: tutorial

Language: en

Sources: [HTTP Toolkit](<https://devfeed.tech/sources/http-toolkit.md>)

Topics: [HTTP](<https://devfeed.tech/topics/http.md>), [Internet Engineering Task Force (IETF)](<https://devfeed.tech/topics/ietf.md>), [client](<https://devfeed.tech/topics/client.md>), [Server](<https://devfeed.tech/topics/server.md>), [stripe](<https://devfeed.tech/topics/stripe.md>)

Tags: [apis](<https://devfeed.tech/tags/apis.md>), [http](<https://devfeed.tech/tags/http.md>), [ietf](<https://devfeed.tech/tags/ietf.md>), [payment](<https://devfeed.tech/tags/payment.md>), [request](<https://devfeed.tech/tags/request.md>), [server](<https://devfeed.tech/tags/server.md>), [standards](<https://devfeed.tech/tags/standards.md>), [stripe](<https://devfeed.tech/tags/stripe.md>), [timeout](<https://devfeed.tech/tags/timeout.md>)

## AI overview

This article explains how idempotency keys make retries safe for HTTP API operations, especially POST and PATCH requests that modify server state. It discusses an IETF draft RFC and the risks of duplicate actions such as payments when clients time out.

## Source excerpt

Idempotency is when doing an operation multiple times is guaranteed to have the same effect as doing it just once. When working with APIs this is exceptionally helpful on slow or unreliable internet connections, or when dealing with particularly sensitive actions such as payments, because it makes retrying operations safe and reliable. This is why most payment gateways like Stripe and Adyen support 'idempotency keys' as a key feature of their APIs. Recently, the IETF have gone further, and created a draft RFC standard for this useful common pattern, as part of the 'Building Blocks for HTTP APIs' working group. This is technically still a draft and the details could change, but it's fairly mature now and increasingly widely used, so it's a good time to take a closer look, and start using & implementing it for yourself. Idempotency in HTTP APIs Many HTTP methods are defined as idempotent in all cases. In theory, any GET, HEAD, PUT, DELETE, OPTIONS, or TRACE operation can be executed multiple times without any unintended side effects (though for badly behaved APIs your mileage may vary). The idea is that an HTTP request like DELETE /users/123 clearly wants to delete that user, and if that accidentally happens twice then that's just fine. User 123 ends up deleted just the same. It's a lot more complicated for POST and PATCH requests, which do not provide that same level of confidence out of the box. These are designed to allow non-idempotent operations, like adding a new user, sending a payment, or appending to existing data. Those are important use cases too - sometimes you really do want to send the same thing twice, and have it happen twice - but this can cause problems when things go wrong. When sending POST and PATCH requests to modify server state, if you want to support retries then both the client and server need to explicitly handle this - which is exactly what idempotency keys are designed to allow you to do. How can non-idempotency go wrong? Without idempoten