What Everstock does, and what it will never do

Everstock connects a supplier's stock feed to your Shopify store and keeps your quantities in step with it. It is deliberately narrow in what it touches: it reads a feed, works out what would change, shows you that list first, and then writes only what you have asked it to write.

What Everstock syncs

Inventory quantity is the default and the core of the product. Sync inventory is on when you create a connection, and for many merchants it is the only thing they ever turn on.

Three further things are optional and start switched off:

• Sync price updates variant prices from the feed. Several supplier feeds carry dealer cost rather than your retail price, so leave this off unless you have deliberately decided otherwise.
• Create missing products creates a product when a supplier item has no match in your store (single variant, initial stock).
• "Product fields (advanced)" on the connection page holds five separate toggles: Sync title, Sync description, Sync vendor, Sync product type and Sync tags. All five are off by default, and the section carries a standing warning, "These fields overwrite your product data". Tags become fully supplier-authoritative once that toggle is on.

Everstock matches supplier records to your products on barcode first, then SKU. That matching key is fixed and there is no setting to change it. You do choose the Shopify location: each connection reads and writes stock at one location, picked when you create the connection and changeable afterwards. Everstock reads and writes the available quantity there, which is the stock your storefront can sell.

One option runs in the other direction. Supplier write-back (advanced) on the connection page pushes your current Shopify quantities out to the supplier instead of reading from it. It is off by default, it is only offered when that supplier's API accepts inventory writes, and nothing leaves your store until you enable it for that connection.

What it will never do

A short, empty or broken feed can never zero your stock. Every sync sorts records into three buckets: records that need a write, records that are already correct and are skipped, and records that a human should look at. A product that is in your store but missing from today's feed goes into that third bucket for review. It never becomes a write, and never becomes a zero.

Two smaller safeguards work the same way. A feed row whose quantity is blank or unreadable is skipped, and your existing stock is left untouched. A Quantity cap (optional) of 0 or less is treated as no cap at all, so a stray zero in that field cannot flatten your catalogue.

New products created by Create missing products are always created as drafts. Everstock never publishes a product for you.

Everstock also never sees your orders or your customers. The app requests exactly five Shopify permissions: read_inventory, read_locations, read_products, write_inventory and write_products. Nothing about orders, fulfilments or customer data is requested or read. Supplier credentials and Shopify tokens are encrypted at rest, and support will never ask you to email an API key or token.

The shape of the workflow

You start on Connections and choose Connect a supplier. In the wizard you pick a supplier or preset, fill in authentication, point Everstock at the inventory endpoint and map the supplier's fields onto Everstock's canonical ones, then set your sync scope and schedule.

Test connection fetches a sample and dry-runs your mapping. It writes nothing. You get a per-record preview showing what Everstock read, with issue chips such as "no matching key" and "quantity missing/invalid" for rows that would not sync cleanly. Fix the mapping until those rows look right, then Save connection.

From there the loop is short. Preview changes is a full dry run against your live store data: it opens "Preview: proposed changes" with the banner "Nothing has been written to Shopify", listing each proposed action with the quantity written as, for example, 5 → 12. Sync now does the same work for real.

Reading the audit trail

Every run, dry or real, lands in Sync history. Open a run to see the Run summary counts (Fetched, Applied, Skipped, For review, Failed), the Fetch log, and a Per-record audit you can filter by item status.

The "For review" count is where you look when numbers do not match your expectation. The audit's Change column gives three reasons a record ends up there: "Unmatched" (the record had no SKU or barcode to match on), "Duplicate" (two supplier records shared the same key), and "Not found in supplier" (a product in your store was not in the feed at all). There is no separate review queue. Review items live inside the run that produced them.

Need help? Visit the support page or email hello@usenormalize.com.