On 13 October, BigCommerce quietly documented something small: you can now filter and sort the V3 Catalog API's product list by available_to_sell, qty_backordered and backorder_limit. It is the kind of changelog entry that gets no coverage at all. It is also the last piece of plumbing that makes native backorders operationally usable, and it landed about six weeks before the busiest trading period of the year.

That timing is the whole reason to pay attention. BigCommerce announced general availability on 30 September, the developer changelog recorded shopper-facing messaging a month earlier on 1 September, and now you can actually query the catalog for everything sitting on backorder. The feature is complete. The question in front of most merchants is not whether BigCommerce supports backorders. It is whether turning them on this close to peak season is a good idea, and what breaks if you do it without thinking.

Our answer, and it is not the answer most posts on this topic will give you: enabling BigCommerce backorders is a ten minute job, and it is the least important part of the work. The important part is that the moment you switch it on, you change what the word "available" means across every system connected to your store. If you have not audited that, you have not enabled backorders. You have introduced a quiet oversell.

BigCommerce backorders: what actually shipped, and when

It helps to see the three releases as one feature delivered in stages, because the staging explains a few things that otherwise look inconsistent.

The beta was announced in a post published 3 April 2026 and covered inventory maths, control panel workflows and APIs only. It deliberately excluded anything the shopper could see. In that phase, "Current Stock" was renamed "Available to Sell" in product and inventory views, import and export files renamed "Current Stock" to "On Hand" and gained backorder columns, and the Inventory REST API picked up backorder limit and quantity backordered.

On 1 September, the developer changelog recorded the shopper-facing half as generally available: messaging across the product detail page, cart, checkout and order confirmation, seven new display settings on GET and PUT /v3/settings/inventory, a stockPosition object on cart and checkout line items carrying quantityOnHand, quantityBackordered, quantityOutOfStock and backorderMessage, plus quantity_backordered on V2 order line items and documented context variables for Stencil and Catalyst.

On 30 September BigCommerce published its general availability announcement for all merchants, which presents that shopper-facing messaging as part of what GA adds. The two sources frame the messaging milestone a little differently, which matters only if you are reconstructing the timeline. All of it is live now. On 13 October the catalog list endpoint gained the filters. If you evaluated backorders during the beta and concluded it was not ready because shoppers could not see anything, that conclusion expired in September.

Available to Sell is the real change

Here is the part worth slowing down for. Available to Sell is not a count of anything. The inventory endpoints calculate it as on-hand inventory, minus safety stock, plus the backorder limit.

Two of those three inputs are not inventory. Safety stock is a buffer you hold back deliberately. The backorder limit is a promise about units that do not exist yet. Only on-hand is a number a person in a warehouse could verify by counting.

This matters because the control panel now shows Available to Sell where it used to show Current Stock. The label changed, the number changed, and the column position did not. Anyone who has been reading that column for years to answer "how many do we have" is now reading a different question's answer. On a product with 0 on hand and a backorder limit of 200, the number on screen is 200.

That is correct behavior. It is also the single most likely source of a bad decision in December, because it is the number a merchandiser glances at before deciding whether to run a promotion.

The messaging is off until you turn it on

There are seven backorder display settings on GET and PUT /v3/settings/inventory, and it pays to be precise about how they default, because the detail changes what a shopper actually sees. Five are booleans, and all five default to false: show_quantity_on_backorder, show_quantity_on_hand, show_backorder_message, show_backorder_availability_prompt and show_default_shipping_expectation_prompt. The other two are the message strings, and those do ship with default copy. backorder_availability_prompt defaults to "More available for backorder", and default_shipping_expectation_prompt defaults to "We ship available items right away, and backordered items as soon as they're in stock".

So there is text ready to go, but every switch that would display it is off. Out of the box, a backorder-enabled store shows a shopper nothing at all.

The default state is therefore the worst of both worlds: a shopper can buy an item you do not have, and nothing anywhere in the purchase path tells them so. They find out when it does not arrive. If you enable backorders and change nothing else, you have built a customer service problem rather than a sales channel.

So treat the messaging settings as part of enabling the feature, not as a refinement to come back to. At minimum, turn on the availability prompt and the shipping expectation prompt, and rewrite both. The supplied defaults are serviceable but deliberately vague: "More available for backorder" tells a shopper nothing about when, which is the only thing they want to know. "Ships in 2 to 3 weeks" is a useful sentence. Anything that does not contain a timeframe is not.

One detail that is easy to miss: if backorders are not enabled for the store at all, these fields are simply omitted from the settings response rather than returned as false. If you are scripting the configuration, check for presence, not just value.

There is also one genuine gap to resolve before you commit. The beta listed specific global inventory settings as eligibility requirements, including out-of-stock behavior set to "Don't do anything" and stock level display turned off. At GA, BigCommerce's developer documentation and its announcement restate only Track Inventory and purchasability, and point to a Help Center article for the full requirements. Whether the remaining beta settings still apply is not stated anywhere in the public developer sources, and the arrival of a show_quantity_on_hand setting at GA sits awkwardly with a requirement never to display stock levels. If your store currently hides out-of-stock products rather than showing them, confirm the current requirements with BigCommerce before you change anything, because that one setting may be load bearing.

Six systems now read a number that means something new

This is the audit that distinguishes a store that has switched on BigCommerce backorders from a store that is actually running them.

The storefront is the obvious one, and the one that mostly takes care of itself. In Stencil, the {{#unless product.available_to_sell}} guard in add-to-cart.html suppresses the Sold Out alert, with the result that the Add to Cart button stays enabled while a product still has backorder capacity, and product detail, cart and order templates receive backorder context variables. Catalyst implements the same display across the product page, cart and product cards. If you are on a heavily customized Stencil theme, that guard is exactly the kind of thing a previous developer may have overridden, so confirm it rather than assuming.

Product feeds are where this gets expensive. If your feed logic treats a positive stock number as "in stock", every backordered product is about to be advertised as available on Google Shopping, on marketplaces, and in any paid campaign keyed to availability. You will pay for clicks on items that cannot ship this week. Decide deliberately whether backordered units should be exposed to feeds at all, and if they should, whether the feed needs an availability value of backorder rather than in stock.

ERP and POS sync is the one that causes silent regressions. Many integrations push a stock figure to BigCommerce on a schedule. If that integration writes inventory through an endpoint that also touches backorder fields, or if it was built to reconcile BigCommerce to the ERP's idea of truth, it can overwrite the backorder limits you just set, on its own timetable, with no error. Confirm what your connector writes before you rely on a limit holding.

Fulfilment is a process question rather than a technical one. Your 3PL or warehouse team is about to receive orders containing units that are not in the building. Someone has to decide whether those orders ship partially or wait, and the people picking need to be told before the first one arrives rather than after.

Low stock alerts quietly stop working as intended, because the threshold is now evaluated against a padded number. A product with a backorder limit comfortably above your low stock threshold may never trigger a restock email again. That is the opposite of what you want going into Q4.

Reporting changes meaning too. Sell-through and stockout rates computed from the sellable figure are now measuring something different from the same metric last year. If anyone compares this December to last December, the comparison is no longer like for like unless you account for it.

A backorder limit is a promise, so derive it from a purchase order

BigCommerce lets you set backorder_limit as an integer per product and per location, or set it to null for unlimited. Unlimited is available. It is almost never the right answer in Q4.

The reason is that BigCommerce tracks the units and not the resupply. There is no field anywhere in this feature for the purchase order that is going to satisfy the backorder, no inbound date, and no link to a supplier commitment. The platform will happily let you sell 400 units you have no plan to obtain, and the shipping expectation message you wrote this autumn will keep telling shoppers "2 to 3 weeks" in January.

So the rule we apply on client stores is simple: a backorder limit should equal units already on a confirmed purchase order and not yet allocated, and nothing else. If there is no PO, the limit is zero. That one constraint converts backorders from an optimism setting into an inventory tool, and it gives you a defensible answer when a customer asks where their order is.

It also makes the 13 October changelog item immediately useful. GET /v3/catalog/products now accepts qty_backordered:greater=0, which gives you every product currently carrying backordered units, and you can sort by backorder_limit or available_to_sell in either direction. That is the query behind a weekly review: what have we sold that we do not have, and does a real PO still cover it. Note that the :min and :max modifiers are inclusive while :greater and :less are exclusive, which is the sort of detail that quietly skews a report.

Worth knowing at the boundary: if an order attempts to exceed on-hand stock plus the backorder limit, the API returns a 409 OutOfStock error. The limit is enforced, not advisory.

What the order record keeps, and why that matters in January

One of the better design decisions here is that the messages shown at purchase time are retained on the order. Line items expose backorder_message, which is null when nothing on that line is backordered, and the order itself carries backorder_shipping_expectation_message.

That means the promise you made is stored next to the order you made it on. When a customer contacts you in January about an order from November, your support team can see the exact shipping expectation that shopper was shown, rather than the message currently on the product page. For anyone who has tried to reconstruct that from theme version history, this is a real improvement, and it is a good reason to write considered message text rather than leaving the defaults in place. Whatever you write is going to be quoted back to you.

Two limits to keep in mind. Digital products cannot be backordered at all; they are always reported as unavailable for backorder, and the values inside a digital line item's stockPosition object are always zero, even if a backorder_limit is somehow set. And if you are querying from the storefront, a cart query needs the cart's entityId or site.cart returns null, while guest order queries need cartEntityId. The REST cart and checkout APIs return stockPosition only when you explicitly ask for it.

The order to do this in before peak season

If you are considering this for Q4, the sequence matters more than the speed.

Start with a short list rather than the catalog. Pick products you reorder on a known cycle and sell consistently, because those are the ones where a backorder promise is actually keepable. A long tail item you order once a year is the worst possible candidate.

Set every limit from a confirmed purchase order, as above. Then turn on the messaging and write the text. Then work through the integration audit: feeds, ERP or POS sync, 3PL, low stock alerts, reporting. Then, and this is the step that gets skipped, place a real order that actually goes onto backorder and follow it through the entire chain. Check what the confirmation email says, what the order record stores, what your ERP received, what your 3PL sees, and what your feed published the next morning. One test order surfaces more than an hour of configuration review.

Finally, decide now what date you turn it off. There is a point in December past which "ships in 2 to 3 weeks" stops being a service and starts being a complaint, and that point is much easier to pick calmly now than in the middle of peak week.

The honest recommendation

BigCommerce backorders are a good addition to the platform, and for merchants with reliable resupply they recover revenue that was previously just lost at the moment of stockout. The feature is well built, the API surface is thorough, and keeping the purchase-time message on the order record shows someone thought about the support burden.

But the calendar matters. If you have not run backorders before, enabling them across the catalog now, with peak season weeks away, means your first real test of a new inventory behavior happens during your highest volume weeks, with the integration audit compressed or skipped. That is a bad trade for most stores.

What we would do instead: enable it now on a handful of products where resupply is certain, run the full audit against that small set, place the test order, and learn the behavior under low stakes. Keep the rest of the catalog as it is through peak. Then roll it out properly in January, when a mistake costs you an afternoon rather than a season.

The exception is the store that is already losing identifiable revenue to stockouts on a small number of fast movers with a confirmed PO on the water. If that describes a product in your catalog, turn backorders on for that product, with a real limit and a message you wrote yourself, before peak.

If you want a second pair of eyes on which products qualify, or on what your ERP connector is going to do to those limits, that is the kind of thing we look at every week. oBundle builds on BigCommerce and only BigCommerce, with a focus on complex catalogs and B2B. Get in touch and we will take a look at your inventory setup before you commit to anything.