BigCommerce deactivates webhooks after 48 hours: poll Sume jobs

When BigCommerce deactivates your webhook, your Sume jobs are not affected: they still run to a terminal state. What you lose is the trigger. The fix is to stop depending on any single push channel and reconcile from Sume by job id, using the status endpoint and its next_poll_after_seconds hint.

The retry timing below comes from the BigCommerce webhooks page; the arithmetic is this post's own.

The BigCommerce retry ladder

BigCommerce lists eleven retry delays and says the sequence ends at a cumulative maximum of 48 hours, after which the webhook is deactivated and a notice goes to the registered app email.

Check the arithmetic

The eleven delays add to 173,040 seconds: 60 + 180 + 300 + 600 + 900 + 1,800 + 3,600 + 7,200 + 21,600 + 50,400 + 86,400. Divided by 3,600 that is about 48.07 hours, which matches the documented 48 hour maximum. In practice, an outage longer than two days costs you the webhook, not just a few events.

What Sume gives you for recovery

These are all documented on the Sume jobs and webhooks pages.

A reconcile loop

Keep a table of orders with the Sume job id you stored at submit time. A scheduled task then walks every job that is not yet terminal, reads its status, and fetches the result when result_ready is true. Do not resubmit a paid request just because your own process timed out; a Sume job keeps running whether or not anyone is watching. Sume's own delivery gives up after 10 attempts at 30 seconds, so the same polling loop also covers the Sume side.

Treat the two webhook systems as optimisations over the same truth: the job record on Sume's side.