How to Sync Inventory Between BigCommerce and NetSuite
Keep your BigCommerce store's inventory levels in sync with NetSuite.
What This Integration Does
Overselling is one of the most expensive failure modes in e-commerce, and it usually traces back to BigCommerce showing stock counts that NetSuite already knows are gone. This workflow treats NetSuite as the source of truth (where receipts and fulfillments hit first) and pushes the resulting on-hand-minus-committed quantity to BigCommerce on a tight schedule.
The job runs every few minutes, pulls inventory from NetSuite via SuiteQL, diffs against the last known value cached in Spojit, and only pushes deltas. Bandwidth and BigCommerce rate-limit usage stay low even with a large catalog.
Prerequisites
- A NetSuite connection with SuiteQL access and permission to read item and inventory tables.
- A BigCommerce connection with
store_v2_productsread/write scope. - Matching SKUs in both systems - SKU is the natural key.
Step 1: Schedule Trigger
Add a Trigger node, type Schedule, running every 15 minutes. More frequent than that is rarely useful (BigCommerce update propagation isn't instant either). Set since to the previous run timestamp.
Step 2: Pull Available Inventory from NetSuite
Add a Connector node calling netsuite run-suiteql. Use a query that returns SKU and available quantity, scoped to items changed since the last run:
SELECT i.itemid AS sku,
NVL(SUM(b.quantityonhand) - SUM(b.quantitycommitted), 0) AS available
FROM item i
JOIN inventorybalance b ON b.item = i.id
WHERE i.isinactive = 'F'
AND b.lastmodifieddate >= TO_TIMESTAMP('{{ since }}', 'YYYY-MM-DD"T"HH24:MI:SS"Z"')
GROUP BY i.itemid
Step 3: Diff Against the Last Known State
Cache the previous run's {sku, available} in MongoDB (collection inventory_state) or MySQL. Add a Transform node that joins this run's results against the cache and emits only rows where available differs. This is the single biggest performance lever - on a 10k-SKU catalog typical runs touch tens, not thousands, of products.
Step 4: Loop and Update BigCommerce
Add a Loop over the diff array. Inside, call bigcommerce get-product filtered by SKU to grab the product id (cache this mapping too), then call update-product:
{
"inventory_level": {{ row.available }},
"inventory_tracking": "product"
}
Wrap the update in a Condition on response status. On 200, write the new available value into the state cache.
Step 5: Handle Variants
For BigCommerce products with variants, inventory is tracked per variant, not per product. Add a branching Condition: if the SKU resolves to a variant rather than a product, use raw-api-request to PUT to /v3/catalog/products/{product_id}/variants/{variant_id} with the new inventory_level instead.
Step 6: Report and Alert
After the loop, post a one-line summary (SKUs updated, failed) to slack send-message. If any single update fails, log the SKU and error to the same channel so the team can fix the mapping or investigate.
Tips
- Use the diff cache - without it you'll burn rate limit hammering BigCommerce on unchanged products.
- Round NetSuite available quantities (committed-inventory can be fractional in odd configurations). BigCommerce expects integers.
- Run the schedule on top of the hour so it lines up with reporting windows and is easy to correlate during incidents.
Common Pitfalls
- Negative inventory - NetSuite can show negative on-hand briefly during fulfilment. Clamp to 0 in the Transform step or BigCommerce will reject the update.
- Multi-location NetSuite - If you have multiple inventory locations, decide which one(s) feed BigCommerce. The default SuiteQL above sums across all locations.
- SKU drift - A SKU changed in NetSuite without being changed in BigCommerce will silently fall out of the loop. Run a weekly reconciliation that flags orphans on both sides.
Testing
Pick a single low-volume SKU. Run the workflow once manually, change the on-hand in NetSuite by one unit, run again, and confirm only that SKU appears in the diff and the BigCommerce inventory_level changes accordingly. Then enable the schedule.