Imagine a store sending a sales order to an inventory system. The system creates the order, but its response does not reach the store in time. If the integration resends it as a new request, operations may see two technically valid orders for one purchase. A successful-connection screen will not reveal this case.
This is a fictional example, not a customer incident. It changes the acceptance question from whether data arrives to what happens when its arrival is uncertain. Before hiring an integration company, request a plan covering retries, unknown outcomes and reconciliation, alongside successful processing.
Distinguish a failed operation from a lost success response
A timeout does not prove the other system did nothing. The connection may fail before delivery or after execution but before the response arrives. AWS's retry guidance explains this risk and how aggressive retries can increase pressure. The supplier therefore needs to explain how it determines state and what it permits to be retried.
Request states your team understands, such as awaiting submission, outcome under investigation, completed and intervention required. Agree their transitions and visibility. A delay should not automatically mean permanent failure, and an unknown result needs an accountable owner.
Operation identity matters more than retry count
Ask how the integration recognizes two attempts for the same operation. Some APIs support an idempotency key for safe repetition under defined conditions; Stripe documents one example. That does not establish equivalent support in every accounting or shipping interface, or unlimited coverage for changed data and key retention.
You do not need to design the key format yourself. You need testable answers: what identifies the business operation, where is it linked to attempts, what happens when quantity changes, and when is a request genuinely new? Request documented limits for the actual interface versions used.
An acceptance sheet connecting faults to effects
Propose these cases in a test environment with fictional data. The technical team determines how to simulate faults safely; do not disconnect services or experimentally resend live orders.
| Case | Expected observation | Acceptance evidence |
|---|---|---|
| Destination unavailable before execution | The operation remains traceable without claiming completion. | A clear state and bounded attempts under the policy. |
| Operation succeeded but response was delayed | The result is checked before another business effect is created. | One order linked to its reference and a record explaining the delay. |
| The same notification arrives twice | The intended effect of that notification is not repeated. | Effect and record review, beyond counting messages. |
| An old notification follows a newer update | The order does not automatically return to an older business state. | A documented ordering decision or current-state check. |
| Retries end with the outcome unresolved | An exception reaches a named owner instead of disappearing. | An alert, intervention route and final decision record. |
| Reconciliation finds a missing operation | The gap is resolved without repeating completed work. | Before-and-after comparison linked to the operation reference. |
These are proposed discussion criteria, not a guarantee that duplicates are impossible. If an interface prevents verification or duplicate control, the offer must explain that limit and the alternative workflow. Safe handling may require pausing for review instead of continuing uncertain automation.
A notification and a business operation differ
Shopify documents repeated webhook deliveries and, in certain circumstances, distinguishes delivery identifiers from event identifiers. That prompts a supplier question: does the solution only ignore the same message twice, or also check the business effect across different channels?
In the store example, an order notification followed by a later query result should not create two inventory orders. Conversely, a new order from the same customer is not a duplicate simply because the phone number matches. The design must explain this distinction without using personal data as an arbitrary test key.
Request reconciliation that operations can use
Specify what is periodically compared: counts alone, or operation references, states and quantities? Identify who receives discrepancies and their authority to resolve them. Include the comparison window and expected API cost in the offer, without assuming unlimited free queries.
Ask an authorized user to try resolving one exception: inspect the reason, check the destination, choose an allowed action and trace the outcome. A button that replays everything can duplicate correct operations if its boundaries are uncontrolled. Decision records belong in acceptance alongside data delivery.
Use the business systems integration guide for the broader picture and integration quote inputs for preparation. Attach the case sheet when discussing systems and API integration so fault testing and reconciliation are explicit scope items.
What the references support
Stripe's idempotent request documentation, Shopify's delivery and duplicate verification documentation and AWS's timeout and retry guidance were opened on 3 November 2026. They support principles and provider-specific limits, not proof of any particular implementation. The scenarios were prepared with AI assistance and review of the content and sources.
