Home Help centre Advanced
Supplier write-back (advanced)
Supplier write-back pushes your current Shopify quantities out to your supplier, which is the reverse of every other sync in Everstock. It is an advanced feature, it is off by default, and most merchants should leave it off: nearly every supplier feed API is read-only and will not accept an inventory write at all.
Where to find it
Open a connection at Connections, then the connection's name, and scroll to the section Supplier write-back (advanced). It lives only on the connection detail page. There is no write-back option in the "Connect a supplier" wizard, on the connections list, or in Sync history.
If the supplier's API cannot accept writes, the section shows an information banner headed "This supplier's API is read-only" with the line "Inventory write-back isn't available for this connection." There is nothing to turn on in that case. Of the presets that ship today, the Demo feed is the only one that supports write-back, and its demo endpoint simply acknowledges how many records it received without changing anything. That makes it the safe way to see a push run end to end.
Turning it on
When write-back is possible, the section shows a Write-back: badge reading Enabled or Disabled, plus a button Enable write-back. That button opens a confirmation titled "Enable supplier write-back?" which states the three things you are agreeing to. It pushes your Shopify inventory quantities to the supplier, the reverse of every other sync on the page. It is a one-way write, and most suppliers do not accept it. A failed push is not retried, and failures are reported per run, not per record.
Once enabled, three buttons appear: Disable write-back, Push preview, and Push now. Saving the setting toasts "Write-back setting saved". Only enable this for a connection you know supports write-back.
What a push actually does
A push reads your current Shopify quantities and sends them to the supplier's write endpoint. Its scope is quantities only: SKU, barcode and quantity are the only fields ever sent to the supplier, never prices and never product fields. A push writes nothing at all to your store. Records with no SKU and no barcode are skipped, because there is no way to tell the supplier which item they are.
Push preview is a dry run and writes nothing anywhere, not to the supplier and not to your store. Its records are logged with status Planned. Push now sends them for real, once, with no retry.
Pushes only happen when you click. They are never scheduled, and no sync frequency setting triggers them.
Reading a push run
Push runs are badged exactly Push in Sync history, in the connection's own Recent runs table, and in the dashboard's Recent sync runs table. The run detail heading reads "Run ·
In the Run summary of a push, Fetched is the number of records read from your store, Applied is the number the supplier accepted, and Skipped is the records that had no SKU or barcode. In the Per-record audit, both the Change and Action columns read Push, and Status is Applied, Failed, Planned, or Skipped. Because failures are coarse, a rejected push marks every pushed record on that run as Failed, so the audit rows never single out which record the supplier refused.
The page does not poll for a push the way it does for a sync. After the toast "Push queued" or "Push preview queued", refresh the connection page or open Sync history to see the finished run.
What push runs are left out of
"Last run" on the connections list and on the connection page shows the most recent real sync only, so previews and pushes are excluded. The dashboard's totals also exclude them and say so. A push never counts as a sync for scheduling either, so it does not move your next scheduled sync.
A push can also be recorded as Skipped instead of running, with the message "Supplier write-back is not enabled for this connection." or "This supplier's API is read-only. Write-back is not supported."
A frozen subscription usually stops the push before any run exists: the click is refused with the message "Your plan is inactive. Reactivate it to run a sync." A run recorded as Skipped with "Plan inactive. Push skipped." appears only when the plan goes inactive after the push was already queued.
Need help? Visit the support page or email hello@usenormalize.com.