Connecting Shopify and Neto With Custom Inventory Middleware

An inventory sync looks simple right up until two systems disagree about what just happened. A product gets edited in Shopify. Stock shifts in the warehouse. A customer checks out while the last update is still working its way through the pipe. Get the order of those events wrong, even for a few seconds, and the storefront ends up advertising stock that isn't actually there.

That was the situation waiting for us on this project. The client needed Shopify and Neto, their warehouse and order management system, to stay aligned across product creation, inventory counts, pricing, product details, and incoming orders. Nothing on that list sounds unusual by itself. The interesting decision was how to build the connection between them.

Why this wasn't a Make or n8n job

Our default for most integration work is a visual workflow tool: point Make or n8n at two APIs and you can usually have them talking within a day. We looked at this one the same way, and talked ourselves out of it. The real constraints here were API rate limits on both sides, webhook reliability, retry behavior, queue management, and a product catalog large enough that one dropped event doesn't just annoy a customer. It corrupts a count that other processes rely on being correct.

A scenario-based tool is built to react to individual events. This integration needed to hold state: to know what it had already processed, what was still mid-flight, and what to do when Neto's API went quiet for thirty seconds in the middle of a batch update. So instead, we built a dedicated Node.js middleware service, running continuously on a VPS, backed by MySQL for a persistent record of what the integration knows and has already done.

What the middleware actually does

The service sits in the middle of two directions of traffic. Products created or edited in Shopify flow down into Neto. Stock levels and pricing changes made on the warehouse side flow back up into the storefront, and incoming Shopify orders flow into the warehouse for fulfillment. Product details stay aligned on both ends.

None of that reduces to a single "when X happens, do Y" rule. It's an ongoing relationship between two systems that each think they own the truth about the product catalog. Running it as a persistent service, instead of a chain of stateless triggers, gave us somewhere to put the retry logic, the queueing, and the recovery behavior for whenever one side is slow to respond.

What held up

We don't have an audited before-and-after accuracy figure for this one, and we'd rather say that plainly than make one up to round out the story. What we do have is a completed integration that's been running, and a decision that held up under the details: when two commerce systems are both allowed to change the same operational data, the state and recovery behavior need to be designed before you pick a tool, not after. The tool is the easy part. The hard part is deciding what happens when an update arrives twice, arrives out of order, or doesn't arrive at all.

If Shopify and your warehouse system keep falling out of sync, talk to us about your workflow.