An integration receives an order notification, creates work in the warehouse management system, and loses its connection before recording success. The next notification arrives. Should it create another task?
That small gap between doing the work and recording that it was done is worth a place in the onboarding demonstration. A clean order-import screen does not answer it.
Repeated messages are an expected design case
Shopify documents that webhook deliveries can repeat, including after a timeout or retry. Its current guidance recommends idempotent processing: repeating an input should not produce an additional effect. It distinguishes a delivery identifier used for deduplication from an event identifier that can correlate deliveries from the same merchant action. Shopify delivery verification.
For an operations buyer, the result matters more than a claim that the connector is “real time.” One authorized fulfillment instruction should produce the intended warehouse work once.
Follow the message all the way to the floor
Ask the integration owner to trace the store order, fulfillment instruction, connector record and warehouse task. Request a masked example with the identifiers still connected. A log that says “duplicate ignored” is helpful, but check that the original task exists and contains the correct quantities.
Deduplicating every message with the same order number would be too blunt. A legitimate revision may need attention. The team must distinguish repeated delivery from new authorized work and apply the current release policy.
Four cases for an acceptance demonstration
Our desk review produced the following proposed test matrix. These are tests to request, not results from a system we operated.
| Case | Evidence to request |
|---|---|
| Same notification delivered twice | Two receipt records, one intended warehouse action |
| Same merchant action reaches multiple subscriptions | Correlation showing which actions are required and which are redundant |
| A genuine order revision arrives | A documented update or hold under the release policy |
| Process stops after the WMS creates a task | Recovery finds the existing task before deciding whether to retry |
The fourth case is particularly useful. If the connector only remembers completion after an external write returns, ask how it handles uncertainty. The implementation might use a stable external reference, a lookup, or another documented control. Have the technical owner explain the actual mechanism rather than prescribing one from a sales call.
Judge physical outcomes, not just message counts
During an approved test, compare task count, reserved quantity and any labels created. Label creation may be a separate operation with its own retry behavior. An integration can avoid a duplicate order record yet still repeat a later action.
Do this in a test environment or with clearly controlled test orders and authorized staff. Do not deliberately interrupt production order processing to see what happens.
Agree who handles the uncertain queue
A system should be able to pause an ambiguous case for investigation without losing it. Ask who reviews that queue, what evidence they see, and how the brand learns an order is waiting. Confirm how a manually resolved case is prevented from being released again by an automatic retry.
The acceptance decision is straightforward: can the team demonstrate the intended warehouse outcome and explain recovery when a response is missing? Until then, “the connector imported the order” is only part of the evidence.
Related reading
Sources
Accessed September 29, 2026. Recheck platform and carrier terms before publication.