Why this matters
Stock counts drift the moment two systems both think they own the number. Your store shows four units left. The warehouse picked three this morning and nobody logged it. The next customer buys an item you cannot ship, and you refund and apologize.
Retyping makes that worse, but it is not the root cause. The root cause is that nobody agreed which system holds the truth for each field. The store is good at taking orders and showing prices. The inventory system is good at bins, receipts, adjustments and location counts. A connection works when you decide once which side wins, then let software carry the value across.
A working link does four things with no person in the loop. It reserves stock when an order is placed. It releases the reservation when an order is cancelled. It posts the shipment when the warehouse packs. It pulls the new on hand count back to the store. Each of those is a small event with a clear owner.
How to connect online store to inventory system is mostly a job of agreeing ownership, not a job of picking a connector. This guide covers the store to inventory link only. The store to accounting link has different rules, mostly around invoices and tax, and mixing the two usually ends with the warehouse team arguing about balance sheets.
Before you start
List every record you plan to move: item, variant, price, stock by location, order, order line, shipment, return, adjustment. For each one, name the system that owns it and the system that only listens. If two people disagree on that list, settle it before you write any code. Every messy sync starts with an unclear owner.
Pick one key for a product and stick to it. SKU works when store variants and inventory items share the same code. If they do not, build a mapping table and treat it as permanent infrastructure, not a spreadsheet you patch later. Watch for leading zeros, stray spaces and case changes. Many systems treat ABC-01 and abc-01 as two different items.
Decide when stock moves. One model reserves at checkout and decrements at shipment, which is safer when you sell on more than one channel. The other decrements at checkout and adds stock back on cancellation, which is simpler but leaves you exposed on failed payments and refunds.
Check the dull details before you connect anything: unit of measure, bundles and kits, backorder rules, multi location stock, and whether the store shows stock from one warehouse or from all of them. Get test credentials for both systems. Find out whether the inventory system supports webhooks or only polling, and what its rate limits are.
How to do it
Build one direction first, then close the loop. Send orders from the store into the inventory system and watch them land as sales orders or pick tickets. Once that flow is boring and repeatable, turn on the return path for shipments and stock levels. Teams that switch both directions on the same afternoon spend the next week untangling duplicates.
Every integration needs a retry policy and a place to put records that keep failing. A dead letter queue sounds dramatic. It is just a table of rejected payloads with the error and the raw body, and it is the first place you will look when someone says an order vanished.
Timestamp everything and store the source system's record id on both sides. Without those two fields you cannot answer the question that matters at 6pm on a Friday: did this order already post, or did it post twice?
- Map the fields and name an owner. Write a field map covering items, stock, orders, shipments and returns. For each field, mark the source of truth and the direction of sync. Share it with the warehouse lead and whoever handles store admin.
- Clean your product keys. Pull a full export from both systems and match items by SKU. Fix duplicates, trailing spaces and case mismatches before they reach the sync. Save the mapping table somewhere versioned.
- Connect the order flow. Point the store's order webhook or polling job at the inventory system and create one sales order per store order. Include line items, shipping method and the customer reference. Test with a single order you place yourself.
- Return shipments and stock levels. When the warehouse packs an order, send the shipment and tracking number back to the store. Then push the new on hand figure for each SKU. If you sell on more than one channel, push a stock buffer rather than the exact count.
- Handle cancellations and returns. Set a rule for what happens when a customer cancels before packing and after packing. A return should create a receipt in the inventory system and a credit in the store, not a stock edit someone makes by hand.
- Add retries and a dead letter queue. Retry failed calls with backoff, cap the attempts, then park the payload. Send an alert to a channel someone actually reads. Keep the raw body so you can replay it after a fix.
- Backfill opening stock with a cutoff. Take a stock snapshot, load it into the inventory system, and note the exact time. Turn on live sync only after that timestamp so no order slips through between the two.
- Put a monitor on the link. Track sync lag, rejected records and orders with no matching shipment. A daily count comparison by SKU catches drift faster than reading logs.
How to check it worked
Run a scripted test in a sandbox or staging store. Place an order for a known SKU and confirm the reservation or decrement appears in the inventory system within your expected window. Cancel a second order and watch the stock come back. Ship a third and check that the tracking number lands on the store order.
Then test the awkward paths. Two customers buy the last unit within a few seconds of each other. A payment fails after the order is created. A customer returns one line from a three line order. A bundle sells and the component SKUs need to drop together. These are the cases that break a link which looked fine.
After a week, compare the two systems directly. Export stock from the store and from the inventory system and diff them by SKU. Small gaps are normal where reservations are in flight. A gap that grows every day means the return path is not landing.
Read the dead letter queue even when it is empty. Check the alert channel works by forcing a bad payload through. If nobody has seen an alert fire, you do not know whether it can.
Mistakes to avoid
Turning on two way stock sync is the classic mistake. Both systems then fight over the number, and the last write wins by accident. Choose one writer for stock and let the other side read it. Keep the sync narrow in other ways too: letting the inventory system overwrite store prices, or the store overwrite warehouse bins, creates arguments that take longer to settle than the integration took to build.
Backfilling historical orders without a cutoff, then wondering why stock is negative, is the second. Load opening balances and a snapshot time instead of years of history, unless you have a reason and a plan to reconcile it.
Skipping alerting because the first two weeks looked clean is the third. Silent failures are normal. A sync that stops at 2am on a Saturday should page someone before Monday's orders pile up.
If the work is bigger than one engineer can carry alongside everything else, an outside build is a fair option. The Systems integration build from Cloudverg is a fixed scope engagement at $12,500/month, runs three to four weeks, starts within 10 business days, and includes an integration map, two or more live integrations with retries and dead letter handling, a field mapping document, alerting, backfill and a runbook with a handover session. Whether you build it in house or buy it, name the person who owns the mapping table after handover.
Frequently asked questions
Should stock sync run in both directions between the store and the inventory system?
No. Pick one system as the stock owner and let the other read. Two way stock sync creates loops where each update triggers the other, and the final number depends on timing rather than reality.
How often should stock levels sync?
Push an update when stock changes rather than on a fixed hourly schedule. Event driven updates keep the store close to real time and reduce the chance of two orders landing on the same unit. If the inventory system only supports polling, poll every few minutes and keep a small buffer on the store side.
What do I do with orders that fail to sync?
Send every failed record to a dead letter queue with the error and the raw payload. Alert someone, fix the cause, then replay it from the queue. Never edit stock by hand to cover a missing order, because the next sync will overwrite it.
Can I connect the store to inventory without a developer?
Hosted connectors cover simple setups where both systems share matching SKUs and you run one warehouse. They struggle with bundles, multi location stock and returns. Budget for a developer or an integration service once you need custom rules.