How We Fixed the Inventory Blind Spot Between Tradegecko and a Legacy Warehouse System

Case Study Highlights

• Systems: Tradegecko (QuickBooks Commerce) + Six Works warehouse

• Problem: No inventory sync, sales team manually checking stock in a separate portal

• Solution: Automated inventory sync

• Result: Sales team works from one screen, no more manual stock verification

A sales rep is taking an order. Tradegecko is open in front of them, and it cannot tell them whether the stock is actually in the warehouse.

So they open a second tab, log into the Six Works portal, look the number up, come back, and finish the order.

That was the job, several times a day.

Nobody designs a workday like that. It accumulates, one workaround at a time, until it’s simply how the work gets done.

Our client runs a wholesale operation on Tradegecko (now QuickBooks Commerce), their command center for sales. For fulfillment they partnered with Six Works, a company that handled the picking and shipping.

What the setup actually looked like

On paper it worked fine:

• Sales in Tradegecko
• Picking and shipping at Six Works
• Basic order and tracking sync already in place

Orders went across. Tracking came back. The one number that never moved between the two systems was the stock level, which is the number the sales team needed most.

So somebody fetched it by hand, every time. Slow, tedious, and wrong often enough to matter.

They came to us at SaaS Glue to close that gap.

We’d seen the shape of it before. A client filing Royal Mail compensation claims spent 20 minutes hunting through purchase orders in Xero for every lost parcel. The number they needed existed. It just wasn’t where they were working.

The reality check

Then we started digging into the Six Works API and understood why nobody had fixed this already.

No webhooks. No polling endpoints. Just a legacy API with two problems that shaped everything after them.

First, it was insecure: static token authentication, no SSL. Sending a client’s wholesale inventory over an unencrypted connection was a non-starter.

Second, it allowed one request per hour. One. Not one per second. Per hour.

That second one sounds fatal, and for plenty of businesses it would be. So before designing anything, we looked at what this client actually sells.

They aren’t a high-frequency B2C shop moving single t-shirts every ten seconds. They move large quantities to other businesses. When you’re holding 50K units of a product, the odds of overselling it in the 59 minutes between updates are remarkably low.

If you sell ones and twos off a shelf holding ten, an hourly sync is no use to you, and we’d tell you that. This client wasn’t that, so we stopped fighting the rate limit and built around it. Finding the balance between future-proofing and cost is most of what we do, and here it landed far closer to the warehouse’s limits than to a real-time sync.

What we built

Our first step was a secure proxy API server sitting in front of the warehouse. It wraps that unencrypted connection in a modern SSL layer, so the source stayed as dated as it always was while the data arriving at Tradegecko was encrypted and compliant with modern standards.

Then the sync itself: every 60 minutes, a complete snapshot of stock levels, pushed into Tradegecko.

That’s less simple than it sounds. Tradegecko supports batch processing, but the endpoint is designed for pushing stock adjustments, not actual quantities. And the current quantity for every single SKU has to be read back from Tradegecko in its own separate call. Stack up enough of those and the figures you started with are stale by the time you finish pushing them.

So we timed it. Real usage patterns showed that a two-minute window carries negligible risk of anything meaningful changing, so we split the full update into chunks, each one sized so its own poll-to-push cycle finishes comfortably inside those two minutes.

The whole process retries with exponential backoff. The API times out or the network drops, and the sync picks itself back up on its own.

And it tells us when something is wrong. A Grafana dashboard with Rollbar logging gives the integration a heartbeat, so if the warehouse API goes down or a sync fails, we hear about it before the client does. That part goes in first on every project. An integration nobody is watching is a rumor.

What changed

The tab-hopping stopped.

The rep taking an order now reads the warehouse’s stock figure inside Tradegecko, on the screen they already had open, and the sales team stopped second-guessing the numbers in front of them.

Nothing about the warehouse API got better. It’s still old and still capped at one request an hour. We just stopped asking a person to be the bridge across it.

The best integrations are the ones you forget are there. This one runs every hour, and the only people who think about it are us, on the days the dashboard has something to say. That’s a core part of how we think about software.

Frequently Asked Questions – Manual Inventory Checks

Would this work with other warehouse systems?

It depends on the API, not the brand. We've connected plenty of warehouse and order systems and no two have been alike. The first thing we look at is what the system will hand over and how often: webhooks, polling, a nightly file, or in this case one request an hour over an unencrypted connection. Once we know that, we know what kind of sync is honest to promise.

What if you need updates faster than once an hour?

Then an hourly sync is the wrong answer for you, and we'd want that settled before anyone builds anything. The limit belonged to the warehouse, not to us, so there was no clever workaround to reach for: either the provider raises the cap or you move to a system that doesn't have one. What made it safe here was the client's order profile, and that is the first thing discovery looks at.

How long did the project take?

About four weeks from the first call to going live, testing and monitoring included. The monitoring went in first, which is how we run every project.

Do you still work with legacy setups?

Often, yes. Ripping out a system because its API is dated is rarely worth what it costs the business, and here the client couldn't have done it anyway: the warehouse system belonged to their fulfillment partner, not to them. Wrapping it in something secure and leaving it where it was beat every version of the plan that started with changing the warehouse.

What does it cost?

We start every build with discovery. It produces a written spec with a fixed price on the build, so you see that number before you commit to it. What moves the price on a job like this is the state of the API at the far end. A modern, documented one is a short job. One that needs a secure proxy in front of it before a single figure can move safely is a longer one.

Still tab-hopping between systems that should share data? Drop us a message. We’ll have a quick chat and see if we can help.

You can also see more of our work or read our manifesto to understand how we approach these problems.