Inventory Stock Sync Agent

What is the Inventory Stock Sync Agent?

Selling the same products on a Shopify store, a WooCommerce site, a BigCommerce store and eBay means keeping several stock counts in step by hand — and the day one of them drifts, you oversell. The Inventory Stock Sync Agent takes one store as the truth, keeps the others at its quantities every hour, and tells you about every SKU it could not settle.

You choose a master store and one or more target stores. For every SKU of the master, the agent works out the quantity each target should hold, compares it with what the target actually holds, and — depending on the mode — reports the difference, records the change it would make, or sets the target quantity and reads it back to confirm it.

The rule is deliberately simple:

target quantity = master quantity − safety stock (never below zero)

The safety stock is a number of units kept back per target, zero by default. There is no rules engine, no percentage split and no per-channel allocation: this agent replicates one authoritative stock, and that is all it does.

What it is, and what it is not

It replicates a stock; it does not count sales. The master is the only source of truth. A target never influences the master, and two targets never influence each other. If a target sells on its own, its stock drops below the master's: this agent does not subtract that sale from the master, and it does not write the master's older quantity back over it either — see A target that dropped on its own below. To have the sales of every channel reach the master, add the Omnichannel Sales Agent.

If your warehouse system, your ERP or one of your stores is where stock is actually managed, make that store the master. If no single place holds the truth, this agent is not the right tool yet.

Which stores are supported?

The master and the targets can each be:

• Shopify — stock is read and set at one location you choose.
• WooCommerce — simple products, and the variations of variable products that manage their own stock.
• eBay — the inventory items of your seller account, by SKU.
• BigCommerce — the units on hand at one location you choose, read and set through BigCommerce's Inventory API. A write sets the variant's absolute stock level at that location (Set Stock Level), never an adjustment. The connection needs the Products (read-only), Store inventory (modify for the agent to write, read-only for Monitor mode) and Store locations (read-only) scopes.
• Square — the count in stock at one location you choose, for variations whose stock Square tracks at that location. A write sets the count (a physical count), never an adjustment. A connection made before Square's writes existed has to reconnect to approve the inventory permissions.
• PrestaShop — the quantity of each combination by its reference, and of each product without combinations. The total of a product with combinations is PrestaShop's own sum: it is never read as a unit, never written. A write sets the quantity, and PrestaShop offers no check against a sale made since it was read (see below). The webservice key needs View on stock_availables, products and combinations, and Patch on stock_availables for the agent to write.
• Odoo — the units on hand, reserved ones included, at one location you choose (that location exactly, not the ones under it), each variant by its own Internal Reference. It needs Odoo's Inventory app: on a database without it the agent says so and does not run. A write is a count, as Odoo's own Update Quantity writes it: Odoo books the difference as an inventory adjustment. A product Odoo does not count, one tracked by lots, or one held in a package or for an owner at that location is reported, never written.
• Wix — the stock of each variant at one location you choose, by its SKU, on a store on Wix Stores Catalog V3. A variant whose quantity Wix does not track (only in stock or not) is reported, never written. A write sets the quantity with the version it read: if Wix recorded a sale since, it refuses the write and nothing is overwritten.

The same provider can be used for the master and a target (two Shopify stores, say), and two targets can be of the same provider — or two locations of one Shopify or BigCommerce store. A store cannot be its own target at the same location, and the same destination cannot be listed twice.

Two agents that write cannot target the same stock, and two writers cannot each target the other's master: the second configuration is refused, naming the first. An agent in Monitor mode writes nothing, so any number of them can watch the same stores.

Three modes

Every agent starts in Monitor. Switching to Auto is the one setting that lets the agent change something at a store on its own, and the screen says so in red where you make that choice.

A target the agent has never compared with the master is only compared on its first run, whatever the mode: nothing is written to it until the agent holds a reading of its own to compare the next one with.

A target that dropped on its own

When a target holds fewer units than the agent last saw there while the master has not moved, the drop may be a sale the master has not counted. Raising the target back to the master's quantity would put up for sale a unit that may already be gone, so the agent never does it on its own: in Auto and Approval modes the change becomes a proposal (UPDATE_PROPOSED) for you to check, and in Monitor mode it is reported (OUT_OF_SYNC) with the same reason. A drop is never treated as proof of a sale.

The case stands while nothing moves. It lifts as soon as the master moves — because an Omnichannel Sales agent applied the sale, or because you corrected the master — or when you approve the change after checking.

Matching is by SKU, exactly

A master SKU is matched to a target item by exact SKU and nothing else. There is no matching by title, no "close enough", and no AI anywhere in the process. When the match is not clean the agent reports it and never guesses:

• a SKU the target does not carry is SKU_NOT_FOUND;
• a SKU that names two items on one side is SKU_AMBIGUOUS — nothing is written until the catalogue is fixed;
• a product without a SKU on the master is counted and skipped;
• a WooCommerce variable product is not stockable itself: its stock lives on its variations, which are matched by their own SKUs;
• on BigCommerce, only tracked items are synced: a product without options tracked at product level, or the variants of a product tracked per variant. An untracked item, or a variant of a product with options tracked at product level — its variants share one count — is reported and never written;
• an archived or trashed product is not for sale and is skipped;
• a target item that does not track stock is NOT_TRACKED — the agent never switches tracking on for you.

Locations

A Shopify store with several locations holding stock, or a BigCommerce store with several locations, must be told which one the agent reads or writes. The agent never sums locations and never picks one for you: until you choose, it waits in "setup required" and says so. A store with a single location needs no choice.

Guard-rails

A wrong master reading — a connection pointed at the wrong store, a location that was just emptied, an import that zeroed a catalogue — would otherwise be replicated to every target within the hour. So every automatic write passes through guard-rails, and each one turns the write into a WRITE_BLOCKED case instead of performing it:

The defaults are conservative on purpose, and you can change them per agent.

Concurrency, honestly

A sale can land on a target between the moment the agent reads it and the moment it writes. On Shopify the write carries the quantity that was read, and Shopify refuses it if the level moved in between. WooCommerce, eBay, BigCommerce, Square, PrestaShop and Odoo offer no such check: the write goes through and erases that sale from the target’s count, until the master moves. The read-back only catches what lands after the write, as WRITE_MISMATCH. The window runs from the moment the agent read that page of the target to the write, seconds on a small catalogue and longer on a large one. If a target on those platforms sells at high volume, prefer Approval mode with a safety stock, or keep its sales flowing to the master with the Omnichannel Sales agent.

How does the agent run?

• Automatically, once per hour. The whole catalogue is compared each time; nothing is assumed from a previous run.
• On demand too, from the agent's page or from ChatGPT.
• Minutes after a sale, with an Omnichannel Sales agent linked. Once that agent has confirmed a movement at the master, the stock sync runs on those SKUs alone — reading them fresh at the master and at every target, with the same guard-rails and read-back — rather than walking the whole catalogue.
• Otherwise, not in real time. On its own the stock sync has no webhook: a sale at 10:05 is replicated during the 11:00 run.

A run reads up to 100,000 stockable items per connection by default. A larger catalogue is reported as truncated rather than partly synced in silence, and a run that reaches its time budget stops cleanly and lets the next run finish.

Exceptions are cases, not alerts

Every result other than SYNCED and UPDATED is a case about one SKU at one target. The same difference seen every hour is one case with a count; when a later run finds the target back in step — because it was written, or because you fixed it by hand — the case closes itself and says so.

Each case carries the SKU, both stores, the target's location when it has one, both quantities, the quantity the agent wanted, the action, the result and the reason in a sentence: enough to understand it without opening either store.

Approving proposed changes

In Approval mode every difference becomes a proposal. You approve or reject each one from ChatGPT or through the API, one at a time or up to 25 at once, and get one answer per proposal.

An approval is for the exact change you were shown. Before writing, the agent reads the master and the target again, recomputes the quantity with your current safety stock and re-applies the guard-rails. If a stock moved in between, nothing is written: the proposal is marked stale and a fresh one replaces it. Approving the same proposal twice writes nothing the second time, and a rejection holds in every mode until the master or the target stock moves.

What a run did, later

What one run decided — every SKU, both quantities, the quantity wanted, the quantity read back after a write, the result and the reason — is kept as that run's own record for 30 days, and does not change afterwards. After 30 days the record says so, rather than showing an empty list.

Reviewing results in Excel and on the web

The agent's page shows where every SKU stands and what each run did. Four live views are available, in the web workspace and as a connected Excel workbook:

• Current stock sync — one row per SKU and target: master and target quantities, the desired quantity, the quantity read back after a write, the action, the result and the reason.
• Open exceptions — the cases that need you.
• Runs — one row per run: SKUs checked, in sync, updated, proposed, blocked and failed.
• Historical run detail — the rows of one specific run, kept for 30 days.

Asking ChatGPT or Claude

With LinkyFlow connected to ChatGPT, Claude or any MCP client:

Set up my stock sync: master "EU boutique", target "Outlet" with a safety stock of 2, in monitor mode.

Run my stock sync now.

Which SKUs are out of sync?

Show me the blocked writes and why.

Switch my stock sync to auto mode.

The last one is a real change at your target stores, and the assistant tells you so before it is made.

Current limitations

• One master, one or more targets, one direction. It replicates an authoritative stock. It does not merge sales from several channels and does not subtract a target's sales from the master — the Omnichannel Sales Agent does.
• Exact SKU only. No matching by title, barcode or similarity.
• One location per connection. Locations are never summed.
• The only write is a stock quantity. Products, prices, titles, listings and orders are never touched.
• Hourly full scan. In between, only a linked Omnichannel Sales agent starts it, on the SKUs it moved; it has no webhook of its own.
• Approving and rejecting proposals is done from ChatGPT or the API for now, not from buttons on the agent's page.
• Detailed run data is kept for 30 days. Run summaries and the current sync stay.

Next steps

• Omnichannel Sales Agent
• Connect Shopify
• Connect WooCommerce
• Connect eBay
• Connect BigCommerce