Integrations # Asynchronous APIs: retry without duplicating work A connection can fail after work has already started. Designing around the operation makes recovery clearer for users and integrations. By ApiNitro ยท September 14, 2026 ## The first response may not be the result When a lookup depends on an external source, keeping a connection open does not guarantee a good experience. An asynchronous workflow can accept the work and make its result available later. In HTTP, a 202 response indicates acceptance for processing; it does not establish that the work completed successfully. Your application needs to represent that difference. Show that the request was received, retain its identifier and let the person continue. A processing state should eventually become a result or a clear failure, without requiring the browser to remain open. ## A retry belongs to the same operation Imagine sending a lookup and losing the connection before reading the response. Submitting another request without context could repeat work that was already accepted. Idempotency lets an API relate those attempts to the same intention, according to its integration contract. Persist the operation's identity before sending and reuse it after a network failure. Different parameters or a different intention require a new operation. Avoid deduplicating solely because two lookups contain identical inputs: checking the same information later may be a new and valid user decision. ## A webhook notifies; your application acts A webhook lets your system receive a notification without continuously checking status. The receiver should verify authenticity using the integration documentation and record delivery before triggering business actions. Receiving a message twice should not start the same downstream process twice. Separating receipt from processing makes recovery easier. Your system might save the notification and then update an internal task. It should also retain a way to retrieve an authorized result when a notification arrives late or cannot be delivered. ## Design recovery before the first failure Retries need pauses and a budget rather than an immediate loop. After an interruption, first ask whether you can recover the existing operation before starting another one. Keep the relationship between request, operation and result so the workflow can be investigated without relying on informal messages. The interface can distinguish pending work, an unresponsive source and a failed notification delivery. These are different conditions. A failed notification does not necessarily mean the result was lost, and it should not turn completed work into a new lookup. ## Applications and agents share the responsibility A REST client and an agent connected through MCP can initiate similar work from different experiences. Both need authorization, tracking and an explicit retry policy. Reconnecting a client should not erase the context of an operation already in progress. Before integrating, test connection failures after submission, duplicate notifications and delayed results. Check what the user sees and which actions your system performs in each case. The goal is to recover the original intention without accidentally creating additional work. ## Sources and further reading - [MDN: 202 Accepted โ†—](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/202) - [Amazon Builders' Library: Making retries safe with idempotent APIs โ†—](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/) [โ† All articles](https://apinitro.com/en/articles/)