Connecting a tyre shop to supplier systems without re-keying

Nearly every tyre retailer we meet is running at least two versions of the truth. The supplier platform says a size is available. The warehouse knows what is physically racked. The webshop shows a third number that was right this morning. Somewhere in the middle sits a person with a spreadsheet, re-keying, and apologising.

It looks like admin. It is actually the ceiling on the business. You cannot promise fast delivery on a number you do not trust, you cannot run paid traffic to listings that might be wrong, and you cannot grow order volume without growing the people who reconcile it.

The first fix is honest modelling. Tyres you physically hold and tyres you can source from a supplier are not the same product state, and pretending otherwise is what produces angry customers. On the platforms we build, the two are tracked separately and surfaced differently, own stock carries the fast delivery promise, supplier stock carries a realistic lead time.

That single distinction removes most of the pain. The customer sees the truth up front, the fast promise stays credible because it is only ever made about tyres on the shelf, and nobody is caught out at fulfilment.

A one-way nightly import is not an integration, it is a snapshot that starts rotting immediately. What actually holds is a two-way sync: availability and pricing flow in from supplier and ERP systems, and orders, invoices and stock movements flow back out, continuously rather than overnight.

The engineering detail that makes it survivable is idempotency. Integrations retry, webhooks arrive twice, a supplier API rate-limits at the worst moment. Every sync operation has to be safe to replay so a hiccup self-corrects on the next pass instead of double-booking a tyre or leaving a product stuck in the wrong state.

Feeds and ERPs are only as honest as the shelf underneath them. If picking and receiving happen on paper, the stock figure drifts no matter how good the API work is, and the drift always surfaces at the customer.

That is why we treat scanning as part of the integration rather than a separate project. Goods received, picked, moved and counted on a handheld means the number updates as stock physically moves, so the ERP, the storefront and the supplier feed are all reading from something real. On DS Scanner, this is exactly the layer that lets a distributor promise same-day delivery and keep it.

• Is there one canonical catalogue, or several competing copies that will always disagree?
• Are own stock and supplier stock modelled separately, with different delivery promises?
• Does data flow both ways, or is it a nightly export that is already stale by breakfast?
• Is every sync operation idempotent, so retries cannot double-book or duplicate?
• Does the warehouse update stock by scanning, or by memory and paper?
• When a supplier API fails, does the system retry and self-heal, or quietly go wrong?

When it is right, the boring stuff disappears. Orders move from checkout into fulfilment without anyone re-typing them, the storefront stops promising tyres that are gone, and the team spends its time on customers instead of reconciliation. Volume can grow without the admin growing with it.

That is the real return on an integration project. Not a dashboard, but a business that can take more orders tomorrow than it did today without hiring someone to keep the numbers in line.