A useful integration needs a failure path: preserve the incoming work, prevent duplicate actions, make exceptions visible, and give an owner a safe way to recover.
Start with the unfinished business action
An integration can appear healthy while the work remains incomplete. A CRM might receive a customer record, but the next task never reaches the operations queue. The question for a business owner is whether someone can find and finish that task without guessing.
Our recommendation is to define success in business terms before connecting the tools. For a customer request, success might mean one saved request, one assigned owner, and a visible next action. Receiving a technical response from a service is only one part of that definition.
Plan for a repeat delivery
Stripe documents that webhook events may be delivered more than once and may arrive out of order. An integration should therefore handle a repeated event without repeating its business effect. The precise delivery behavior depends on each provider.
For an illustrative scheduling workflow, replaying the same request should not create a second assignment. Ask the delivery team what identifies the original request, where that identifier is retained, and how the system distinguishes a retry from a genuinely new instruction.
Give the team a recovery queue
A useful exception record tells an operator what was attempted, what completed, and what still needs attention. Include the original request reference, a readable reason, the last attempt time, and a named owner. Keep credentials and unnecessary customer data out of diagnostic text.
Do not make retry the only available action. Sometimes the input needs correction, the record needs cancellation, or the downstream system has already completed the action. A person should be able to inspect the actual state before deciding.
Consider an illustrative order handoff: request 104 is saved locally and sent to the destination, but the reply times out. The destination might already have created the order. Show this as an unknown outcome that needs reconciliation, not as proof that nothing happened.
| Observed state | What the operator needs to see | Next action |
|---|---|---|
| Saved, not yet sent | The original request reference, destination and assigned owner. | Submit through the controlled processing path and record the attempt. |
| Sent, outcome unknown | The attempt time, original reference and missing confirmation. | Check the destination by that reference. If the result cannot be established, escalate before repeating a consequential action. |
| Destination order found | The destination order identifier and whether the expected status matches. | Link the existing order and verify completion; do not create another one. |
| Confirmed absent after reconciliation | Evidence that no order was created and any input error that has been corrected. | Use the agreed retry mechanism and original business reference, then verify the final record. |
Agree on a small acceptance exercise
Before launch, ask the team to demonstrate a normal request, a duplicate, an unavailable destination, and a delayed response. In each case, follow the business record rather than only watching a success banner.
The exercise is complete when an operator can identify unfinished work, recover it safely, and confirm the final result. If recovery requires a developer to search raw logs every time, include the missing operator workflow in the scope.
Add a delayed-confirmation test to the demonstration: let the destination create the record while the sender receives no timely response. The operator should still be able to discover that record, link it to request 104 and close the exception without duplicating the order. The implementation depends on what the destination API can verify.
Choose how much reliability the workflow needs
A daily internal summary and a customer-facing dispatch queue do not need the same response time. Define an acceptable delay, who handles exceptions, and when the team should temporarily return to a manual process.
We recommend treating the failure path as part of the first integration release. It is easier to agree on ownership while the workflow is being designed than after a customer has asked why nothing happened.
Primary references
The guidance above is AgenticShip's proposed approach. These references provide technical background for the relevant recommendations.