Real-Time Inventory Sync Across Multiple Suppliers: The Hard Parts

Real-time inventory sync across multiple suppliers means every supplier’s stock position is reflected on your platform fast enough that a buyer never orders something that is already gone. The hard part is not the API call. It is reconciling stale feeds, rate limits, reservations and returns into one number a buyer can actually trust.

Every marketplace founder we talk to assumes this is a two week job. Pull stock from each supplier, write it to a table, show it on the product page. Then the first supplier sends a CSV by email once a day, the second has an ERP with no API at all, the third runs on a platform that throttles you after five calls a second, and a customer orders 40 bags of cement that were sold an hour ago in a different city.

This piece covers the parts that actually consume the budget. The examples are from marketplaces in India, where GST invoicing and e-way bill rules add a compliance layer that most international write-ups skip entirely.

Why real-time inventory sync breaks in production

Almost nothing in a multi-supplier catalogue is actually real time. What you have is a set of feeds with different freshness, different reliability and different definitions of the word “available”.

Four failure modes account for most of the incidents we see after launch:

• Stale reads presented as live. A product page says “In stock” because a webhook arrived eleven hours ago. Nothing in the UI tells the buyer how old that number is.
• Out of order updates. Supplier sends quantity 40, then quantity 12. Network jitter delivers them in reverse. Without a sequence number or a supplier side timestamp, your database happily stores 40.
• Double counting across channels. The same physical pallet is listed on your marketplace, on the supplier’s own site and on a third party channel. Three systems each think they can sell all of it.
• Silent feed death. A supplier rotates an API key, your poller starts getting 401s, and because the last known stock is still in your table the catalogue looks perfectly healthy. We have seen this run for nine days before anyone noticed.

The last one matters most, because the system fails in the direction that looks fine. Any sync design that does not treat feed silence as an error state will eventually sell stock that stopped existing weeks ago.

Decide who owns the stock number first

Before writing any integration code, settle a product question: when your platform and the supplier disagree, who wins?

There are three workable answers, and picking the wrong one causes months of pain.

• Supplier is the source of truth. You cache their number and never modify it. Simple, and the right default for a discovery-led marketplace where the supplier fulfils and invoices directly. The cost is that you cannot promise availability at checkout, only likelihood.
• Platform is the source of truth. Suppliers consign stock into your warehouses and you own the count. This is the only model where you can genuinely guarantee stock, and it is the model that requires warehousing, staff and working capital.
• Split ownership by SKU. Fast moving items sit in your warehouse and you own the number. Long tail items stay with the supplier and are shown as “available on request” with a confirmation step. Most Indian marketplaces that scale past a few hundred suppliers end up here.

Write the answer down per SKU, in a column, not in a design document. The checkout flow, the cancellation policy and the refund SLA all branch off this field.

Push, pull and file drops: three patterns compared

You will not get to choose one pattern. A catalogue of 50 suppliers will use all three at once, and your ingestion layer needs to normalise them into a single internal event shape.

A practical rule: build the pull path first even when a supplier offers webhooks. Webhooks get missed, and a periodic reconciliation pull is the only thing that catches drift. Push gives you speed, pull gives you correctness, and you need both.

Normalise units before you normalise anything else

In construction and industrial categories this is the quiet budget killer. One supplier quotes steel per metric tonne, another per kilogram, a third per piece of a given length. Cement comes in bags of 50 kg from one dealer and in tonnes from another. If your ingestion layer stores the number without a canonical unit and a conversion factor per SKU, every downstream price comparison is wrong, and nobody will notice until a customer does.

We covered how this plays out in a materials catalogue in our guide to building a construction materials marketplace. Consumer brands hit the same wall on a hosted platform, which we unpack in Shopify vs custom build for Indian D2C brands.

Rate limits set the real ceiling

Teams plan sync frequency around what the business wants. The platform APIs decide what you actually get. These are published, current limits worth budgeting against before you promise anyone a one minute refresh:

Shopify publishes its calculated query cost model by plan in the GraphQL Admin API rate limits documentation, and Amazon lists per-operation quotas in the Listings Items API rate limits reference. Read both before you size a sync worker pool.

Three things follow from the numbers. First, poll frequency has to be tiered: a fast moving SKU with daily volume deserves a two minute refresh, a slow one does not. Second, you need a per-supplier token bucket in your own code so one noisy integration cannot starve the rest. Third, your queue needs priority lanes, so a stock-out event for an item currently in somebody’s cart jumps ahead of a routine catalogue refresh.

Reservations, not subtraction

The single most common architectural mistake is treating available stock as one mutable integer that gets decremented at checkout. Under any real concurrency, two requests read 1, both decide there is stock, both write 0, and two customers get a confirmation for the same item.

The fix is to stop storing a number and start storing a ledger. Available quantity becomes a derived value: on-hand minus active reservations.

1. Write reservations as rows, not as a decrement. Each reservation has a SKU, a quantity, an owner, a created time and an expiry. Available is computed as on-hand minus the sum of unexpired reservations.
2. Reserve at cart or at payment initiation, not at order creation. By the time an order record exists the customer has already been told yes. A short hold, typically 10 to 20 minutes, covers the payment window.
3. Expire holds with a job, and make expiry idempotent. Abandoned carts must release stock automatically. A reservation that is already expired or already converted must be safe to process twice.
4. Serialise per SKU, not per table. In PostgreSQL, a row level lock with SELECT ... FOR UPDATE on the inventory row, or SKIP LOCKED for queue style consumers, keeps contention scoped to the one SKU being contested instead of blocking the whole catalogue.
5. Make every supplier message idempotent. Store the supplier’s own event ID and reject duplicates. Webhooks get retried, and a retried “sold 5 units” applied twice is a phantom stock-out.
6. Carry a timestamp on every stock value and show it. “Stock confirmed 4 minutes ago” is honest and it converts better than a bare “In stock” that the buyer has learned not to believe.

Point six is a product decision more than an engineering one. In a multi-supplier model you usually cannot promise certainty, so sell confidence instead: show freshness, show the supplier’s fulfilment track record, and make the confirmation step fast.

GST invoicing and e-way bills in a split order

This is where Indian marketplaces diverge sharply from the international playbook. A single buyer cart that draws from three suppliers is not one invoice. It is three supplies from three GSTINs, and the compliance layer has to be designed alongside the inventory layer, not bolted on later.

Three constraints shape the build:

• E-invoicing threshold. Mandatory e-invoicing currently applies to businesses with aggregate annual turnover above ₹5 crore. Your supplier base will straddle the line, so the platform has to support both IRN-backed invoices and ordinary GST invoices at the same time.
• The 30 day reporting limit. A GSTN advisory applies a 30 day reporting window on the Invoice Registration Portal for taxpayers with AATO of ₹10 crore and above, covering invoices, credit notes and debit notes, effective 1 April 2025. Past that window the portal refuses the document. Reported in this summary of the GSTN advisory. If your platform batches invoice generation, that batch job is now a compliance risk, and a stuck queue becomes an unfixable invoice.
• E-way bills. Under Rule 138 of the CGST Rules, an e-way bill is required for movement of goods where consignment value exceeds ₹50,000, as set out in the GST Council’s e-way bill flyer. In construction and industrial categories most orders clear that in a single line item, so e-way bill generation is a core flow, not an edge case.

Practically, this means your order model needs a sub-order per supplier from day one, each carrying its own GSTIN, place of supply, HSN codes, tax split and document references. Retrofitting that into a flat order table after launch is one of the more expensive rewrites we get called in to do. It is also why we treat invoicing and inventory as one workstream in custom software development projects rather than two.

Suppliers who will never call your API

In most Indian B2B categories, a meaningful share of your supply base runs on Tally, WhatsApp and a notebook. No API is coming. Pretending otherwise is how marketplaces end up with a beautiful integration layer and an empty catalogue.

What works instead:

• A supplier app with a two tap stock update. One screen, the SKUs they actually sell, and a toggle plus a quantity field. If updating stock takes longer than replying to a WhatsApp message, it will not happen.
• Confirm-to-sell for unsynced SKUs. Show the item, take the order as a request, and give the supplier a short window to confirm. The buyer waits minutes instead of discovering a cancellation a day later.
• Decay stale listings automatically. If a supplier has not confirmed a SKU in N days, demote it in search and mark it unconfirmed. Do not let an untouched row keep selling.
• Measure acceptance rate per supplier and rank on it. Suppliers who keep stock current get more traffic. This is the only lever that reliably changes behaviour, and it is a ranking feature, not a sync feature.

The last point is the real answer to the data quality problem in a two-sided market. We wrote about the wider dynamics of that in building a two-sided marketplace, and about why procurement in this sector stays stubbornly manual in construction procurement software in India.

Build versus buy

Off-the-shelf inventory and order management suites solve a different problem: one seller across many sales channels. A marketplace is many sellers into one channel, which is the inverse. The SaaS tools are also tiered on volume. Zoho Inventory, for example, caps its plans by monthly orders and stocking locations, from 500 orders and 2 locations on the entry tier up to 15,000 orders and 10 locations at the top. A marketplace crosses location counts like those on day one, with a dozen supplier warehouses. Use SaaS for your own stock, build the supplier sync layer yourself.

A real-time inventory sync build checklist

If you are scoping this work, these are the items that decide whether the system holds up at 50 suppliers:

1. Source of truth recorded per SKU, not assumed globally.
2. Canonical units with a per-SKU conversion factor, applied at ingestion.
3. Both push and scheduled pull for every supplier that supports an API.
4. Per-supplier rate limit budget, with backoff and jitter.
5. Priority queue so cart-affecting events jump the catalogue refresh.
6. Reservation ledger with expiry, replacing integer decrement.
7. Idempotency keys on every inbound supplier event.
8. Freshness timestamp stored and displayed to the buyer.
9. Feed-silence alerting, so a dead integration pages someone within hours.
10. Sub-order per supplier GSTIN, with IRN, HSN and e-way bill fields present from the first schema.
11. A nightly full reconciliation that diffs your numbers against each supplier’s and reports the drift.

Item eleven is the one teams skip and then wish they had not. You cannot improve what you do not measure, and drift percentage per supplier is the single metric that tells you whether real-time inventory sync is actually working.

Go Material, a construction materials platform we built, surfaces live prices and availability by location across a supplier network, which is exactly the class of problem described above. The Go Material case study covers what was built.

Scoping a multi-supplier sync layer?

If you are planning a marketplace where stock accuracy decides whether buyers come back, settle this before the schema is locked. Send us your supplier mix and our custom software development team will map which integration pattern each supplier needs, what sync frequency is realistic against their platform limits, and how the GST and e-way bill flows hang off it. You get a scope you can price, not a headline number.