BigCommerce and CodeWords: automating store operations
Order routing, inventory reconciliation across channels, supplier chasing, and the store work that arrives every day and belongs to nobody in particular.
On this page
A store that is working generates a steady stream of small obligations. An order needs routing to the right fulfilment path. Stock needs to agree across the store, the warehouse, and whichever marketplaces you also sell on. A supplier needs chasing. A customer needs telling that the thing they ordered is delayed.
None of these is difficult. All of them are daily, and they tend to belong to whoever notices, which is why they get missed on busy days — exactly the days when missing them costs most.
What we'll cover
- Where store operations leak time
- What the BigCommerce API reaches
- Connecting it to CodeWords
- Eight automations worth building
- Inventory across channels
- Building it so it survives
- Limits worth knowing about
- Frequently asked questions
Where store operations leak time
Order triage. Most orders need nothing. Some need attention: an unusual quantity, a mismatched billing address, a customer who has charged back before, an item that is actually out of stock. Finding those means someone scanning the list.
Stock disagreement. The store says four, the warehouse says two, the marketplace listing says six. Overselling is the expensive outcome and it is discovered by the customer.
Supplier chasing. Purchase orders outstanding, restocks due, and the tracking of who has confirmed what. Held in someone's memory or a spreadsheet neither of you updates.
Customer communication between the confirmation and the delivery. Delays, partial shipments, and back-orders. The silence between those two emails is where most support tickets are created.
Reporting. Yesterday's numbers, this week's best sellers, what stopped selling. Available, and nobody assembles them.
What the BigCommerce API reaches
Orders can be listed, read, updated, and searched, including line items, shipping addresses, and status. Order status transitions are the hook most automation hangs on.
Products and variants can be read and updated, including inventory levels, which is the centre of any stock automation.
Customers can be read, created, and updated, with attributes and customer groups, which matter for segmentation and pricing.
Catalog operations cover categories, brands, options, and modifiers.
Price lists allow customer-group pricing, which is how wholesale and tiered arrangements are usually expressed.
Webhooks fire on order, product, customer, and inventory events, which is what makes reactive automation possible rather than polling.
The useful framing: orders and inventory are where the daily work is, and webhooks are what let you act the moment something happens rather than on a schedule that is always slightly late.
Connecting it to CodeWords
CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.
- Open CodeWords and start a new automation.
- Describe what should happen in plain language to Cody, the automation builder, naming BigCommerce and the other systems involved.
- Authorize the connection when prompted. BigCommerce uses API accounts with per-scope permissions, so grant only the scopes the automation needs.
- Describe the exceptions alongside the happy path: an order for a product that no longer exists, a stock level that would go negative, a supplier who does not respond.
- Test against a sandbox store or a small set of real orders before scheduling anything.
You describe the outcome; Cody builds it, connects it, and deploys it. When the process changes you describe the change. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.
Eight automations worth building
Order triage. Every order checked against your own rules — value thresholds, address mismatches, unusual quantities, first-time customers ordering heavily — with anything flagged raised to a person and everything else passed through silently. This is the highest-value one because it turns scanning a list into reading a short exception report.
Fulfilment routing. Orders directed to the right path based on contents, destination, and stock location, with the fulfilment system told what to do. Manual routing is the step that scales worst as volume grows.
Low-stock and reorder alerts. Thresholds per product, accounting for how fast each one actually sells rather than a flat number, with a purchase order drafted for review.
Delay communication. When an order sits unfulfilled past your normal window, tell the customer before they ask. This measurably reduces support volume and costs nothing to build.
Back-order handling. When stock arrives, find who was waiting, allocate in order, and notify them. Doing this by hand is where the mistakes and the goodwill both go.
Supplier chasing. Outstanding purchase orders tracked and followed up on a schedule, with confirmations recorded against the order rather than in an inbox.
Daily operations summary. Orders, revenue, exceptions, stock warnings, and anything unusual, delivered before the working day rather than assembled during it.
Review and feedback requests. Triggered on delivery rather than on dispatch, which is a small change that noticeably improves response rates.
Inventory across channels
Worth separating, because it is where most store automation projects actually founder.
Decide the system of record. One place holds the truth about stock. Everything else follows it. Without that decision, two systems will disagree and each will have a good argument.
Reserve on order, not on fulfilment. Stock committed to an unfulfilled order is not available to sell, and a system that only decrements on dispatch will oversell during any busy period.
Sync on events, reconcile on a schedule. Event-driven updates keep channels close to current. A nightly full reconciliation catches the drift that events inevitably miss, and reporting the differences is more useful than silently fixing them.
Build in a buffer for fast movers. For products that sell quickly across several channels, holding back a small margin absorbs the latency between systems. It costs a little availability and prevents the oversell.
Handle the negative case deliberately. A stock level that would go below zero indicates something is already wrong. Stopping and flagging is better than writing a negative number and continuing.
Building it so it survives
Make it safe to run twice. Webhooks retry. An automation that creates a fulfilment or sends a customer email needs a guard, since both are visible when duplicated.
Never let an automation cancel or refund unsupervised. Prepare it, surface it, let a person approve. The cost of getting this wrong is not recoverable through better error handling.
Report the outcome. A daily line with counts processed and exceptions raised is what makes silence meaningful.
Respect the customer's experience. Automated messages about delays should be specific and infrequent. Three automated updates about the same delay is worse than one.
Log what was decided. When a customer asks why their order was routed a particular way, or why they were told something, the log is the difference between an answer and a guess.
Limits worth knowing about
Rate limits vary by plan and are enforced per store, so bulk catalog operations need pacing. The API reports your remaining quota in response headers, which is worth using rather than guessing.
Catalog operations are heavier than order operations. Updating many products is the thing most likely to hit limits, and it should be batched and scheduled rather than triggered on demand.
Webhook delivery is at-least-once, which is precisely why idempotency matters.
Inventory is tracked at variant level where variants exist, so an automation written against the product rather than the variant will behave unexpectedly on anything with options.
Payment and personal data flow through order objects. Copy what the process needs, and be deliberate about what an automation writes into systems outside your store.
Frequently asked questions
Should I use BigCommerce's own automations?
Wherever they cover the case, yes — they are native and there is nothing extra to maintain. Reach outside when the logic depends on systems BigCommerce does not see, such as your warehouse, your suppliers, or your other sales channels, which is where most operational work actually lives.
How do I stop overselling across channels?
Decide a system of record, reserve stock when an order is placed rather than when it ships, sync on events, reconcile nightly, and hold a buffer on fast movers. Overselling is nearly always a latency problem rather than a data problem, and the buffer is what absorbs latency.
Can an automation issue refunds?
It can, and it should not without approval. Prepare the refund with the reasoning and let a person confirm. Money leaving the business is the category where an automated mistake is least recoverable.
What is the best first automation?
Order triage. It produces an immediately visible benefit, it is easy to check because you can compare its flags against what you would have flagged, and it removes the daily scan that nobody enjoys and everyone skips when busy.
How do I handle products that no longer exist?
Decide before it happens, because it will. An order referencing a deleted product should flag rather than fail silently, and an automation that assumes every SKU resolves will break on exactly the orders that most need attention.
Can I sync to a marketplace as well?
Yes, and treat it as another channel following the same system of record. The rule that saves you is that no channel is ever authoritative about stock except the one you designated, however tempting it is to trust whichever system you happen to be looking at.
How much history should the daily summary cover?
Yesterday, with a comparison against the same day last week rather than against the day before. Retail has a weekly rhythm, and comparing Monday to Sunday produces alarming numbers that mean nothing.
How do I test order automation without real orders?
Use a sandbox store, then a narrow filter on the real store — orders above a value, or from one shipping region — so the first live runs touch a handful of cases you can check by hand. Order automation is the category where a mistake reaches a customer directly, so the cautious ramp is worth the extra day.
Should automations email customers directly?
Transactional and lifecycle messages, yes: delays, back-orders, delivery confirmations. Anything promotional belongs in your email platform with the consent handling that lives there. Mixing the two produces the situation where an unsubscribe silently stops delivery notifications.
What is the right threshold for low-stock alerts?
Not a flat number. Base it on how fast each product actually sells and how long its supplier takes to restock, so a fast mover with a six-week lead time alerts earlier than a slow one you can reorder in days. A single threshold across a catalog either floods you or arrives too late.
How do I handle partial shipments?
Decide the customer communication first and the data second. Most stores under-communicate here, and an automation that tells someone what shipped and what is still coming removes a predictable support contact. Record the split against the order so later queries do not have to reconstruct it.
What to build first
Start with order triage. The benefit shows up on the first run, you can check its flags against what you would have flagged yourself, and it removes the daily scan that gets skipped on exactly the busy days when it matters.
Two things make the difference between a first automation that sticks and one that gets abandoned. Run it alongside whatever happens now for a cycle or two and compare the outputs, since the differences are nearly always genuine discoveries rather than bugs. And have it report that it ran even when it found nothing, because an automation whose only output is silence is one nobody can distinguish from a broken one.
What happens during a sale or a launch?
Volume arrives faster than usual and every latency in your stock sync becomes visible at once. Widen the buffer on fast movers before the event, check that nothing is polling on a slow interval, and make sure the exception report goes somewhere watched rather than to an inbox nobody reads on a Saturday.