Who this is for
Owner of a BigCommerce store whose orders stopped arriving in a fulfilment, accounting or notification system you built or control.
Orders placed over the last days are in BigCommerce but not in the connected system, and nobody knows when it stopped.
The result
Your receiving automation answers order notifications correctly under test with synthetic payloads, the webhooks are active again for the scopes you list, and a gap list names every order that was missed.
What is included
- The webhooks you have for orders: scopes, destination address and whether each is active
- The receiving automation or script you control, its answer codes, speed and handling of repeated notifications
- The window when notifications were missed, and a list of the orders in that window that the connected system lacks
- Corrections to the receiver on a copy, tested with synthetic notifications
You receive
- A note naming why notifications stopped, based on the evidence you send
- The corrected receiver logic on your copy: immediate 200, repeat handling, safe retry behaviour
- The exact steps to list the webhooks and set them active again, with no keys in the document
- A gap list of order IDs in the missed window, compared with the connected system
- A short monitoring checklist for catching a deactivated webhook next time
What is not included
- Re-creating webhooks after an app uninstall or a deleted API account; that is a larger rebuild
- Fixing a third-party connector you cannot change
- Importing the missed orders into the connected system for you
- Payment, shipping or tax problems in the store
- Changes to the BigCommerce store itself
What we need from you first
- What the receiver is and how it is hosted
- The date orders were last seen in the connected system, and the first missing one
- Whether you received an email about a webhook being deactivated
- The scopes you subscribed to, such as order created or status updated
- What changed around the time it stopped: address, host, certificate, automation plan
Never send passwords, keys, customer records or confidential code in the first enquiry. Secure handover is agreed after scoping.
How we check it is done
- The receiver copy answers a synthetic order notification with HTTP 200 before processing, and records it
- The same synthetic notification sent twice produces one record in the connected-system test target
- A burst of synthetic notifications is all acknowledged, with none returning an error status
- The gap list names every order ID present in the store and absent from the connected system for the missed window
You review the tests and the gap list and sign off before payment. Changing the live receiver, re-activating webhooks and catching up the missed orders are steps you take.
When we would stop or decline
- The receiver is a third-party service whose behaviour you cannot change
- The webhooks were deleted because the app was uninstalled or the API account was removed
- The connected system itself rejects the orders for account or billing reasons
- The missed window is longer than the order list can reliably cover and needs a separate recovery plan
Questions
Do you need my BigCommerce API credentials?
No. You run the webhook list and re-activation under your own account with our steps.
Will you import the missed orders?
No. You get a list of exactly which orders are missing. Loading them into your connected system is a separate step.
How long does BigCommerce keep trying?
BigCommerce documents a retry schedule that lasts 48 hours, after which it deactivates the webhook. We name what we tested against.
Price and terms
From £345 · untested offer price. After the agreed checks pass and you sign off; no payment before sign-off.
This is a new service with no published client results. The price is a starting point we have not yet tested with buyers. Nothing is ordered or charged by the enquiry. The full specification is on the Synthetic Industry catalogue.