What is idempotency?
Networks retry. Users double-click. Payment providers resend. Idempotency is why none of that charges anyone twice.
In short
Idempotency is the property of an operation that has the same effect whether it runs once or many times, so a retry, a double click or a redelivered webhook cannot charge a card or send an email twice. It is usually enforced with an idempotency key the server remembers.
Also called: Idempotent operation, Idempotency key
What goes wrong without idempotency when requests repeat?
The same action happens twice: a second charge, a second email, a second order. In a demo every request succeeds the first time. In production, requests time out halfway, phones lose signal, and providers resend events they are not sure you received, so anything that moves money or sends a message has to assume it will be asked twice.
A common Lovable example is a Stripe payment that lands while the upgrade does not, or lands twice; our article on a customer who paid but was not upgraded traces that failure.
Which HTTP methods are idempotent?
By the HTTP standard, GET, HEAD, OPTIONS, TRACE, PUT and DELETE are idempotent; POST and PATCH are not guaranteed to be. MDN's example makes the difference clear: sending the same POST that adds a row three times adds three rows, while deleting the same record three times leaves it deleted, even though the later replies say 404.
Payments, sign-ups and messages are almost always POST requests, which is exactly why they need help.
How does an idempotency key stop a double charge?
The client attaches a unique key to the request. The server records the key with the result the first time, and on any repeat returns that saved result instead of acting again. Stripe's API works this way: every POST request accepts an Idempotency-Key header.
- Stripe suggests a V4 UUID or another random string with enough entropy, up to 255 characters, and no personal data such as email addresses.
- It saves the status code and body of the first request, including 500 errors, and returns them on a retry.
- It errors if a retry reuses a key with different parameters, and may prune keys once they are at least 24 hours old.
How do you make an operation idempotent in a Supabase app?
Give each action a permanent name and let the database refuse a second one. A unique index on that name, for example a payment's provider id or an email's ledger key, means a repeated insert fails instead of creating a duplicate, whatever path the request took. The PostgreSQL documentation describes that guarantee: a unique index rejects duplicate values.
Our entry on the database index covers it in more detail.
Duplicate charges and double sends are the kind of fault we fix in a vibe coding rescue, usually by adding exactly this: a key, a unique index and a handler that returns the first result.
Common questions
Is idempotency the same as deduplication?
Related, not the same. Deduplication drops repeated messages; idempotency makes repeating an operation harmless, whether or not the repeat is detected as a duplicate. An idempotency key does this: the server records the key with its first result and returns that result on any repeat.
Is a POST request idempotent?
Not by default. MDN lists POST and PATCH as methods that are not guaranteed to be idempotent: sending the same POST three times can create three records. That is why Stripe accepts an idempotency key on every POST request, so a retry returns the first result instead.
What should I use as an idempotency key?
A random value with enough entropy that two different actions never collide, such as a V4 UUID, which Stripe suggests. Generate it once per action and reuse it for every retry of that action. Stripe allows up to 255 characters and advises against personal data such as email addresses.
How long does Stripe remember an idempotency key?
Stripe's API reference says keys can be removed once they are at least 24 hours old; reuse a key after that and Stripe treats it as a new request. Within that window, a retry with the same key returns the saved first response, including an error, rather than acting again.
Go deeper
Lovable Stripe integration: set it up safelyHow the Lovable Stripe integration works, built-in payments vs your own Stripe account, and the webhooks, keys and tests a paying app needs before launch.
Related terms
Read next
Sources
- Stripe API reference: Idempotent requests
- Wikipedia: Idempotence
- RFC 9110: HTTP Semantics, Idempotent Methods (June 2022)
- MDN Web Docs: Idempotent
- PostgreSQL documentation: Unique Indexes
Sources checked October 24, 2026
More on this: Production architecture & security · All glossary terms
Built something in Lovable you want people to rely on?
We are the engineers who take it the rest of the way — secured, tested, released and supported.