BigCommerce order notifications and shipping setup: what the store promises and what your systems must do

Orders reach other systems through short notifications

A BigCommerce store does not push full orders to the systems that depend on it. It sends a short notification, an identifier and a scope such as an order being updated, to an address registered with an API account, and the receiving system fetches the order. The receiver must answer HTTP 200. If it does not, BigCommerce retries on a schedule of 11 attempts over 48 hours and then deactivates the webhook, emailing the subscribing app's registered address. After that, new orders are not announced and the connected system shows no error, because nothing arrives to fail.

• The notification carries an ID, so the receiver has to fetch the order.
• Deactivation after retries run out is silent from the shop owner's side.
• The email goes to the app's registered address, which may not be the owner's.

Shipping is organised as zones, methods and carrier connections

BigCommerce's shipping model has three parts. Zones define the regions you deliver to. Methods are attached to zones and decide what a shopper can choose there; the documentation's example offers free shipping, weight-based rates and a live-rate carrier in one zone. Carrier connections link your account with live-rate carriers such as UPS, FedEx and USPS. A checkout always has one consignment, which assigns line items to shipping addresses, and shipments are created only from finalised orders. A shipping problem therefore starts with one question: which zone and which method was the shopper offered.

• Zone: where you deliver.
• Method: what is offered in that zone.
• Carrier connection: how live rates are fetched, where used.

What a connected system needs to do

A receiver should acknowledge first and process afterwards, record each notification, ignore repeats, and fetch the current order rather than trusting the notification's timing. BigCommerce says duplicates may occur, and the usual protection is a temporary list of processed hash values. Whoever owns the integration should also know where the deactivation email goes, and should compare order counts between the store and the connected system on a schedule, because the notification path alone cannot prove nothing was missed.

What a paid outcome here covers, and what it does not

The fixed job for a deactivated order webhook corrects a receiver you control, tests it with synthetic notifications, lists the orders in the missed window and gives you the steps to reactivate the webhooks under your own account. The standing sync service runs a weekly comparison and explains up to two separate causes of difference a month; the correction itself is the fixed job. Neither changes your live store or holds your credentials. Third-party receivers you cannot change, and a webhook deleted because an app was uninstalled, are outside the fixed job, and a fixed job for carrier quote faults is not offered at this time.