Customers expect a single decision to produce a single result. One order. One appointment. One account. Integration design has to preserve that expectation when the network gives an ambiguous answer.
Imagine a hypothetical customer portal sending an order to a fulfillment service. The service accepts it, but the response never reaches the portal. The screen displays an error, and the customer tries again.
Now the business may have two orders and one understandably annoyed customer. The first request worked well enough to cause trouble. The second worked beautifully.
A timeout leaves a question open
A failed response and a failed business operation are different observations. Treating them as equivalent creates a dangerous recovery procedure: keep repeating the request until something looks green.
The buyer-level acceptance question is straightforward: if the caller cannot tell whether the action succeeded, how does the integration establish the outcome or make another attempt safe?
An answer should identify the original business operation, the destination record if one exists, and the evidence used to decide whether another attempt is safe. A new random identifier for every attempt can make the system see several unrelated requests where the customer intended one action.
Real APIs make this distinction explicit
Stripe's idempotent request documentation describes keys that allow supported requests to be retried without repeating the operation. Its API versions have different retry behavior, so the implementation must follow the exact API contract.
There is a separate delivery concern in Stripe's webhook guidance: consumers need to handle duplicate events. A response to an API request and a later notification about that activity are different parts of the workflow.
These are examples of documented platform behavior, not evidence about a One Blink client. They illustrate why “we retry on failure” is an incomplete design answer.
Ask for a replay demonstration
For the portal example, a useful test would simulate the response disappearing after the destination accepts the order. Then repeat the original attempt and inspect both systems.
The result should preserve one business order, provide an explainable receipt, and let an operator distinguish a duplicate attempt from a genuinely new order. Next, deliver the same notification twice and verify that downstream work stays consistent.
Also test a changed request using an existing operation identity. Silently treating a new shipping address or amount as the old request can be wrong in a different direction. The correct behavior depends on the contract; it should be intentional and visible.
Keep a short acceptance record for each test: the original operation identity, the requests sent, the destination record count, the observed result and the person accepting it. Include an interruption beyond the provider's documented retry or key-retention window; the system should surface uncertainty instead of quietly creating a fresh order.
Do this in a safe test environment. Production customers should not become the acceptance fixture.
Give uncertainty somewhere to go
Some outcomes require reconciliation. A provider may offer limited lookup, a retention window may expire, or an operator may need to inspect conflicting records. Those cases need a queue with a named owner and enough context to resolve the operation.
Record the original operation identity, attempt history, destination references and verification result. Protect sensitive payloads rather than copying every customer field into every log. The goal is a defensible answer, not a sprawling archive of private data.
This is a focused extension of integration scoping: specify behavior when the evidence is incomplete, alongside the normal field mapping and success path.
Buy the recovery behavior with the integration
An integration proposal should include safe replay, duplicate handling and reconciliation acceptance criteria wherever the workflow needs them. Otherwise the build can appear complete while the operational problem is waiting for its first interruption.
For teams reviewing custom application or integration work, bring one business action that must never be duplicated. It creates a much more useful technical discussion than a general request to make the systems reliable.
The second attempt is where the architecture reveals what it understood about the first.
