Job bigcommerce-order-webhook-deactivated-orders-not-syncing · revised 11 October 2026
Get BigCommerce orders flowing again to the system that stopped receiving them
The receiving automation answers order notifications correctly under test, the webhooks are active again, and a list shows which orders missed the gap so you can catch them up.
You might be seeing
- New orders are missing from the connected system from one day onward
- Some orders arrive and others never do
- The same order shows up twice
- An email from BigCommerce said a webhook was deactivated
No passwords, keys, card details or admin invites needed to start.
What usually happened
BigCommerce tells the connected system about an order with a short notification that must be answered with an HTTP 200. If the receiver is slow, answers with another status, is unreachable or too many answers fail in a short window, BigCommerce holds notifications back, retries them for 48 hours and then deactivates the webhook, after which orders are never announced and nothing in the connected system shows an error.
Who it’s for: Owner of a BigCommerce store whose orders stopped arriving in a fulfilment, accounting or notification system you built or control.
Usually starts when: 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.
Check whether this job fits
Five questions, about two minutes. Your answers stay on this page unless you choose to email them.
Checks you can run yourself
Find the last good order
Compare the newest order in the connected system with the order list in BigCommerce.
Look for: The time of the first missing order, which sets the start of the gap.
Read the webhook list
Have your administrator list the webhooks and look at the active flag and the destination address.
Look for: A webhook marked inactive, or a destination that no longer matches the receiver address.
What you get
- 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
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
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
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
The receiver copy answers a synthetic order notification with HTTP 200 before processing, and records it
Evidence: Request and response logs with timing, and the stored record
The same synthetic notification sent twice produces one record in the connected-system test target
Evidence: The test target records and the request log
A burst of synthetic notifications is all acknowledged, with none returning an error status
Evidence: The response log for the burst
The gap list names every order ID present in the store and absent from the connected system for the missed window
Evidence: The two ID lists and the difference
Sign-off. 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.
If it fails. If the checks do not pass, you do not pay, and we hand over what we found so anyone can continue.
When it fits, and when we stop
It fits when
- The receiver is an automation, script or small service you control and can copy for testing
- You, or your administrator, can list and update the store's webhooks with your own API account
- You can send an order ID list from the store and from the connected system for the missed window
- The destination uses HTTPS on the standard port
We stop and tell you if
- 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
What could go wrong
The previous receiver logic is kept and described so you can restore it, and the handover explains how to set a webhook inactive again if the new receiver misbehaves.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| Re-activating the webhook releases a burst of events the receiver cannot take | The receiver acknowledges first and queues, and the handover says when to re-activate and how to watch the first hour. |
| Acknowledged notifications are lost because processing fails later | The receiver records each notification before answering and the gap list catches anything missing afterwards. |
| Customer order data is sent to us | We ask for order IDs and timestamps only, and delete them after sign-off. |
A second reviewer checks that no key or order data is in any file, that the receiver cannot lose a notification it acknowledged and that the gap list arithmetic is right.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Read the receiver description, the webhook list and the first missing order time
- Work out how the notifications failed: unreachable, wrong answer code, too slow, or many failures in a short window
- Correct the receiver on the copy: answer immediately, process afterwards, ignore repeats, return an error only for real faults
- Test with synthetic notifications, including a repeat, a malformed one and a burst
- Build the gap list from the two order ID lists and write the re-activation and monitoring steps
- Independent review, then hand over; you apply the receiver change and re-activate the webhooks under your own account
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, the total price, a start window and a delivery date before you accept. Work starts only after agreed inputs, secure access, any licences and necessary permissions are in place. Platform, app and supplier charges are excluded unless the written quote includes them. No charge or booking is created by an enquiry.
Need to keep it working?
Discuss ongoing monitoring of webhooks and order counts as a separate standing agreement.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- BigCommerce documents the answer rules, retry schedule and re-activation; if the receiver is yours and simple, setting the webhook active again after fixing the answer may be enough.
- If a third-party app does the receiving, ask its vendor for its own error log for the missed window first.
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.
Send an enquiry
Send us
- 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
Later, once you agree
- A copy of the receiver logic and configuration, with secrets removed
- Order ID lists for the missed window from the store and from the connected system
- The current webhook list with the destination and active flag, copied by you from your own account
- A company-controlled secure handoff agreed before access: no live passwords, keys, private code or customer records by ordinary email.
You keep the store, the API account and all keys. We never receive credentials; you run the list and re-activation requests under your own account using our steps, and we work on a copy of your receiver.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “bigcommerce-order-webhook-deactivated-orders-not-syncing” as the subject.