Smart Sync and Full Sync

DropStream has two ways of syncing inventory: Smart Sync for routine, frequent updates, and Full Sync for periodic reconciliation. Both run on the schedules you configure per connection, and both can be triggered on demand from the Inventory channel card.

Smart Sync

Smart Sync fetches current quantities from the warehouse and pushes a level to the channel only when the quantity has changed since DropStream’s last recorded value for that SKU. Unchanged SKUs are skipped on the way out.

DropStream’s recorded value for a SKU is the last quantity the warehouse reported — typically the warehouse’s own available figure. DropStream does not recompute available from on hand and committed; it uses what the warehouse sends.

Use Smart Sync for the day-to-day case. It’s the default, runs every 60 minutes out of the box, and it keeps each store accurate without flooding the channel with no-op updates.

Trigger a Smart Sync now. From the connection page, on the Inventory channel card, click Update inventory.

Full Sync

Full Sync fetches current quantities from the warehouse and pushes every SKU to the channel, regardless of whether the value has changed. It’s slower and costlier, but it reconciles every drift — items the channel may have edited locally, items the channel never received because of a transient error, items added since you last ran one.

Full Sync has its own schedule on the Inventory channel card, independent of Smart Sync. By default the Full Sync schedule is empty — Full Sync runs only when you trigger it manually — but you can add a recurring schedule for it.

When to run a Full Sync:

• Once when you first enable inventory for a connection. This initializes the channel’s stock against the warehouse’s actual figures and pushes the result to the store.
• On a recurring schedule, off-peak, no more than once per day — for example, at 1:00 AM. Heavier than that strains both DropStream and the channel without changing anything Smart Sync wouldn’t have already caught.
• When troubleshooting — if a channel and the warehouse appear out of agreement on a SKU, a Full Sync will overwrite the channel with what the warehouse reports.

Trigger a Full Sync now. On the Inventory channel card, click Full inventory update.

Side-by-side

Choosing a sync frequency

A common instinct is to push the sync schedule as fast as possible — “every 5 minutes if you can” — to keep the channel “as close to real-time as possible.” It’s an understandable impulse, especially when an oversell would be expensive. Most of the time, faster is not better. The honest goal is to keep the channel close enough to the warehouse that customers don’t see availability that no longer exists, not to mirror every change instantly.

A handful of moving parts shape what “close enough” actually means.

The channel already tracks its own inventory between syncs

Shopify, Amazon, BigCommerce, the major marketplaces — they all decrement their own count when a customer places an order, without waiting for an inventory update from DropStream. Between two DropStream pushes, the channel’s level is being adjusted in real time by purchase activity on that channel. The DropStream push is the channel re-synchronizing with the warehouse, not the channel learning that it sold something. Even with a 60-minute schedule, the channel’s number is correct minute-to-minute for the orders it’s processing on that channel.

The push from DropStream matters when something changes that the channel can’t see on its own: stock arriving at the warehouse, a count adjustment, an order shipped from another channel that drew down shared stock. Those events happen on a cadence of minutes-to-hours, not seconds.

The pipeline has its own latency

A sync isn’t instantaneous. The full pipeline for one SKU is roughly:

1. The warehouse posts an inventory snapshot or an update event.
2. DropStream pulls (or receives) it.
3. DropStream resolves listings and bundles, applies any partitioning strategy, and queues a push for each store.
4. The store’s API accepts the update and processes it.
5. The store-side cache, search index, and product page eventually reflect the new number.

For a large catalog — tens of thousands of SKUs across several stores — step 2 alone can take many minutes. A “fast” schedule that runs every 15 or 30 minutes against a catalog whose sync takes 20 minutes doesn’t make the channel any fresher; it just produces overlapping runs, where each run is operating on data the next run is already replacing. The data appearing on the channel is just as stale as it would be with a slower cadence — but the system is under constant load while producing the same result.

Channel APIs have rate limits and quiet hours that punish overuse

Every major channel rate-limits its inventory API: requests per second per app, requests per minute per shop, daily quotas on marketplace operations. A 20-minute sync running every 30 minutes is making API calls roughly 40 minutes out of every hour. That competes with:

• Order import and fulfillment events on the same connection.
• The store’s own scheduled tasks (analytics, exports, app integrations).
• Other apps in the merchant’s account that share the same rate-limit pool.

When you get throttled, the channel doesn’t refuse politely — it queues, retries, or drops updates. Inventory ends up less accurate after a throttling event than it would be on a sane schedule, and the throttling can persist beyond the sync window itself.

Worked example: a 20-minute sync on a 30-minute schedule

Imagine a Smart Sync that takes 20 minutes to complete for a large catalog, scheduled every 30 minutes. The timeline looks like this:

0:00  Sync A starts
0:20  Sync A finishes      ← channel reflects warehouse data from ~0:00
0:30  Sync B starts        ← reads warehouse data from 0:30
0:50  Sync B finishes      ← channel reflects warehouse data from ~0:30
1:00  Sync C starts

The channel’s number is, on average, ~10 to ~20 minutes stale at any moment — the same as it would be on a 60-minute schedule (where the average staleness is ~30 minutes). Going faster than the sync duration gets you 10 minutes of freshness in exchange for double the API load.

If the sync schedule is set to 15 minutes instead, every run starts while the previous one is still running. Depending on the platform’s job scheduling, the next run is either queued (no benefit) or skipped (worse than the slower cadence). Either way, the channel doesn’t end up fresher.

A reasonable rule of thumb

• Match the schedule to how often the data actually changes. If your warehouse reports new figures every hour, a sub-hour schedule is mostly re-pushing the same numbers. If physical inventory only shifts a few times a day (truck arrivals, batch adjustments), even a 4-hour Smart Sync is enough.
• Keep the Smart Sync interval longer than the sync’s run time. A safe ratio is 2× — if a Smart Sync takes 20 minutes, run it every 45–60 minutes.
• Use Inventory Partitioning instead of frequency when oversells are the worry. A Safety Stock buffer prevents oversells from the inventory level being slightly stale; faster syncs don’t.
• Reserve Full Sync for off-peak windows. Daily at 1 AM is a strong default; faster than that wastes API budget without reconciling anything Smart Sync wouldn’t have already caught.
• Watch the Activity tab on a SKU detail to see real run times for your account, and tune from there. Tuning from observed timing is more honest than picking a number that “feels fast.”

Bundles in both modes

For bundle products, DropStream computes the bundle’s channel quantity from the components every time it pushes. Smart Sync re-pushes the bundle when any component’s level changes; Full Sync re-pushes every bundle.

How sync mode interacts with listings

In both modes, DropStream pushes the level under the channel SKU on the listing — not the warehouse SKU — when a listing exists. If no listing exists for a SKU on a store, the warehouse SKU is pushed as-is. The mode determines whether to push; the catalog and listings determine what SKU to push under.