A company store needs two ways to recover order information: timely event updates and an independent check against the system that owns the order. If an update goes missing, repair the record before asking anyone to order again. A missing shipment notification is not proof that a shipment failed, and a stale dashboard is not authorization to manufacture a replacement.
This guide helps operations and IT agree on a recovery contract before connecting a store to reporting, support or fulfillment tools. It concerns orders already placed—not eligibility for a new employee gift. The decision is how much automation your program needs, how to detect a silent gap and who may correct it.
Publisher perspective: Brand Sauce provides company-store services. These are proposed integration requirements, not claims about a particular Brand Sauce API, connector or monitoring service. Confirm available interfaces, implementation scope, support ownership and quote-needed costs with your provider. Official Shopify documentation supplies concrete platform examples; it does not establish that another platform behaves identically. Sources checked October 8, 2026.
Start with a status contract, not a connector name
“The order syncs” is too vague for purchasing or acceptance. Ask what information moves, in which direction, at what level of detail and with what delay. A daily reporting export and an instruction that releases a garment to production have different consequences when they fail.
Shopify’s order-status documentation separates payment, fulfillment, order and return states. It also distinguishes partial fulfillment from fulfillment of all items. That is a useful reason not to compress every business condition into one green “complete” label.
For your own program, agree on the following mapping. The descriptions are recommended business definitions, not universal vendor field names.
| Record | Question it answers | Do not infer |
|---|---|---|
| Order accepted | Was this selection recorded by the store? | That funds cleared or production started |
| Production release | Did the responsible supplier accept the work? | That every line item is ready |
| Fulfillment | Which item quantities have been dispatched? | That the recipient received the whole order |
| Delivery evidence | What does the shipment record currently report? | That a recipient dispute is resolved |
| Credit or replacement | What remedy was approved for which original item? | That replaying an old update should create another remedy |
Assign an authoritative source to each row. The store may own selection details while a production partner owns acceptance and a carrier supplies tracking scans. Finance may own approval for an adjustment. One dashboard can present those facts without becoming the authority for all of them.
Choose a recovery model your team can operate
A webhook is an event notification sent to another system. Shopify’s webhook overview describes near-real-time updates but explicitly says delivery is not guaranteed and events are not guaranteed to arrive in order. It recommends periodic reconciliation: fetching source data independently to repair inconsistencies.
The buying implication is straightforward: “supports webhooks” should start the reliability conversation, not end it. Choose the least complicated arrangement that still exposes missing work within your program’s acceptable window.
| Model | Reasonable fit | Operational tradeoff |
|---|---|---|
| Controlled export and review | Small program with a named reviewer and nonurgent reporting | Manual effort; gaps remain invisible until the review |
| Scheduled source fetch | Predictable refresh requirements and an available read interface | Refresh delay, access maintenance and provider query limits |
| Events plus source reconciliation | Frequent orders or support workflows that need timely updates | More moving parts; someone must own both processing and repair |
Do not buy real-time complexity solely because the store is on-demand. A low-volume on-demand program may work with a disciplined daily review. A bulk campaign can still require detailed line-item updates when deliveries split across offices. Hybrid programs should explicitly join the batch purchase to the individual distributions; receiving one bulk carton does not establish that every employee has received an item.
Keep order, item and shipment identities intact
Require stable identifiers for the organization, store, order and line item. Add fulfillment or shipment identifiers where available. A human-readable order number can help support, but it should not be assumed unique across unrelated stores. A recipient’s email is a contact detail, not a reliable substitute for an order key.
Consider an illustrative welcome order containing a jacket and a notebook. The notebook ships first. If the receiving report matches only on order number and replaces “unfulfilled” with “shipped,” it may imply that the jacket also left. A better record preserves shipped quantities for each line and keeps the remaining jacket visible.
Require the same precision for corrections. A replacement shipment should point back to the affected item rather than overwrite the original tracking history. A credit should remain distinguishable from a fulfillment update. This supports later invoice, shipment and credit reconciliation, but this operational recovery check should happen before the monthly financial close.
Separate receiving a message from completing the work
The technical owner should show two checkpoints: safe receipt and completed processing. A server response alone does not demonstrate that the support dashboard, production system or notification queue was updated successfully.
Shopify’s delivery-verification guidance calls for authenticating HTTPS deliveries, handling duplicates and responding quickly. It describes queueing as a way to process work asynchronously. For Shopify specifically, the complete HTTPS request has a five-second timeout. Those are platform requirements, not a service commitment for your finished integration.
Our recommended acceptance requirement is that authenticated input be stored durably before it is acknowledged as safely received. The work then needs its own processing state: pending, completed or failed with a reason. Have engineering demonstrate what happens if a worker stops after receipt but before the destination is updated.
Duplicate handling also needs two levels. Repeated delivery of the same message should not repeat an action. Independently, two distinct messages about the same shipment should not generate two identical recipient emails or release the same replacement twice. Ask for a persistent action record and a controlled retry path; an in-memory “already seen” list does not survive a restart.
For gift eligibility upstream of checkout, use a separate entitlement rule. Our guide to preventing duplicate employee gifts during HR imports addresses that different boundary. Reliable order updates cannot fix a policy that authorized two gifts in the first place.
Design the independent reconciliation pass
The recovery job should compare source records with the receiving system and identify missing orders, missing item updates and conflicting values. It should not simply count messages. Ten notifications could all concern one order; nine orders could still be absent.
Ask the implementer to document these five decisions:
- Coverage: Which stores, order types, statuses and historical periods are included? Can it see canceled orders and late adjustments?
- Checkpoint: What marks the last fully completed scan? An interrupted scan must not advance past records it never examined.
- Overlap: How are boundary-time updates revisited safely? A small repeated lookback can help, but its size must fit the source’s behavior.
- Completeness: How are all result pages fetched, and what happens when access expires or a query limit is reached?
- Repair: Which differences can be corrected automatically, and which become an owned exception?
Those are design questions to test against the actual interface. If the provider supplies only a limited export, write down the limitation. Do not describe an export that omits older corrections as a full historical audit.
Automatic repair is generally easier to justify for a reporting copy than for a new physical action. Updating a stale tracking field and sending another jacket are not equivalent. Keep production releases, refunds and replacements behind their approved business controls even when technical reconciliation discovers the discrepancy.
Do not let a late update erase newer evidence
A delayed message can arrive after a cancellation, shipment or manual correction. The integration should evaluate the source version or relevant timestamp, and fetch current source state when needed, rather than treating arrival time as truth. Shopify’s ordering caveat is particularly relevant here.
Do not solve this with a simplistic status ladder in which “higher” always wins. Returns, cancellations, edited quantities and replacement shipments do not form one straight progression. Have the implementation preserve history and apply rules for each record type.
For an illustrative outage, suppose the store recorded a shipment while the reporting connection was unavailable. Support then saw “awaiting shipment.” When service resumes, reconciliation finds the source shipment and repairs the report. It should not submit a second order merely because support’s earlier screen lacked tracking. If a replacement was already approved manually, that decision must be visible before any automated action runs.
Give the recovery queue an owner
An exception record should contain the scoped order reference, affected items, source evidence, discrepancy type, first detection time, last attempted repair, owner and next action. Keep personal addresses and full payloads out of broad operational summaries unless they are genuinely needed. Authorized support staff can open the source record for details.
Agree on freshness targets by consequence. A daily merchandising report can tolerate a different delay from a production hold. Targets are your operating choices; do not present them as measured platform performance until you have evidence.
- IT: Own failed delivery, processing errors, authentication, subscription health and incomplete scans.
- Store operations: Own unclear item mappings, supplier-state conflicts and release decisions.
- Recipient support: Own communications and approved remedies, without treating a stale report as shipment evidence.
- Program owner: Own acceptable delay, escalation coverage and the decision to pause an affected automation.
Track the age of the oldest unresolved exception and the time of the last complete reconciliation. A quiet queue is not reassuring if the scan itself stopped. After an incident, verify both recovery of affected records and restoration of the mechanism that will detect the next gap.
Make these six failures part of acceptance
Use synthetic orders in an approved test environment. Ask the provider to show the source state, receiving state, action history and exception queue for each test—not merely a successful connector setup screen.
| Test | Required business outcome |
|---|---|
| One event is withheld | The independent scan finds and repairs the missing update |
| The same event arrives twice | No second notification, release or remedy occurs |
| An older update arrives last | Newer source evidence is not silently overwritten |
| Only one of two items ships | The unshipped item remains clearly outstanding |
| Processing stops after receipt | The work is recoverable and does not disappear behind a success response |
| The reconciliation scan fails halfway | An alert identifies incomplete coverage; the next run recovers the unexamined records |
Record the evidence and unresolved exceptions in your company-store pilot acceptance review. If a critical recovery test fails, narrow the automation’s scope or retain a controlled manual process until the gap is fixed.
Frequently asked questions
Can we rely on webhook retries alone?
No. Retries help with delivery failures, but do not prove that every business update was processed correctly. An independent source comparison covers a different failure mode.
What if the provider has no API?
Ask for a complete, consistently identified export and a documented review cadence. Test whether it includes partial shipments and corrections. If the available records cannot support your required recovery window, change the requirement, add a supported service or choose another workflow.
Should reconciliation send missing customer emails automatically?
Only under an explicit notification policy. Repairing data does not always justify sending an old message. Check current status, prior sends and whether the message would still help the recipient.
The purchase requirement is not “a connected store.” It is an order record that can recover from missing information without creating new physical or financial mistakes.
