A missing API response does not prove that the server did nothing. A service may create an application and then lose the connection before the client receives confirmation. Repeating the request could create another application. Operations affecting records or payments deserve particular care. DEFINE THE OPERATION MDN describes idempotence as the same intended effect from one request or several identical requests. POST does not guarantee this property by itself. Decide whether retries are safe for the actual operation rather than relying on a retry button. A PRACTICAL DESIGN Give each business operation a stable identifier and retain its state and result. A repeated call can then return an existing outcome. If a provider supports an idempotency key, check its lifetime and rules in that provider’s documentation. Do not create a new key for every network retry of the same operation. HANDLE UNCERTAINTY Show a checking status, limit retries and inspect the previous operation before starting another one. Log a technical correlation identifier without API secrets or payment details. Test lost responses, double clicks, delayed processing and service restarts. A reliable interface depends on server-side behaviour, not just disabling a button. Source: https://developer.mozilla.org/en-US/docs/Glossary/Idempotent Explore the DomainEvery catalogue for your next project. https://domainevery.com/en/domains