BigCommerce Bug Fixing: 12 questions answered.
Frequently asked questions about fixing BigCommerce bugs, Stencil build errors, Handlebars partials, API 429s, checkout SDK, and webhooks.
My integration keeps getting 429 Too Many Requests, how do you fix it?
A 429 means your integration is exceeding BigCommerce’s API quota for your plan. The fix is rarely “ask for a higher limit”, it’s adding exponential backoff, respecting the X-Rate-Limit-Time-Reset-Ms header, batching writes, and moving heavy reads to the GraphQL Storefront API or webhooks instead of polling. We rebuild the integration so your ERP, PIM, or shipping sync stays inside the quota and stops dropping data.
How much does it cost to fix a BigCommerce bug?
A single, well-defined BigCommerce bug starts at $99 (Quick Fix, ~4h @ $25/hr) with a 24-48h turnaround. A batch of bugs or one deep root cause, like a failing Stencil build or an unstable Checkout SDK flow, is the $499 Bug-Fix Sprint (~20h @ $25/hr). Down-store emergencies and ongoing cover are quoted as a retainer, with a $2,499 stabilization sprint (~100h @ $25/hr) available for deep rebuilds. You always get a fixed price before any work starts.
My custom checkout (Checkout SDK) is broken, can you debug it?
Yes. A custom build on the BigCommerce Checkout SDK or a misconfigured Optimized One-Page Checkout can throw on load, skip the shipping or payment step, or fail to take payment. We debug the SDK flow end to end, the checkout service calls, the step rendering, and the payment provider integration, reproduce it on a sandbox, fix the failing call, and verify a real test order completes before going live.
Is there a guarantee on the fix?
Yes. Every fix carries a 14-day warranty: if the same bug returns within 14 days of sign-off, we re-fix it at no charge. We also hand back a short write-up of the root cause and what changed, so you’re never left guessing what was done to your store. For broader stability, the Emergency / Retainer tier keeps us on call.
A Handlebars partial or helper is breaking a page, what causes it?
How fast can you fix an urgent BigCommerce bug?
For an emergency, a down storefront, a failing checkout, or a Stencil build that won’t deploy, we open a triage thread within 4 working hours and prioritise it ahead of standard tickets. A single well-defined bug is typically fixed in 24-48 hours. A larger sprint depends on scope, but you get a clear SLA window in our first reply, before any work begins.
A Script Manager tag is throwing errors on my storefront, can you fix that?
Yes. A broken Script Manager entry, a GA4 tag, a marketing pixel, or a custom script, can throw an uncaught error that breaks other storefront JavaScript (including add-to-cart or the variant picker). We find which Script Manager tag is failing, fix or correctly gate it (right location, right page scope), and confirm the console is clean again.
Do you work on a sandbox or directly on my live store?
Sandbox or local Stencil preview first, every time. We reproduce the bug on a stencil-cli preview or a sandbox store and fix it there before anything touches your live storefront. Because theme changes ship via stencil bundle + Git, the live push is a reviewable, revertible theme version, not a blind edit in the file browser. API and webhook changes are tested against a sandbox store too.
My Stencil theme won’t build or activate, can you fix it?
Yes. stencil bundle or stencil push failures (“Could not activate theme”, webpack/BrowserSync build errors, a broken config.json, or a missing dependency in package.json) are one of our most common BigCommerce fixes. We reproduce the build locally with Stencil CLI, read the actual build log, fix the offending template or config, and push a clean bundle. The theme deploys through Git so you can roll back any version.
My product variant options show the wrong price or image, fixable?
Yes. Variant pickers showing the wrong price, image, or stock usually trace to an option-set / SKU mapping problem, a stale theme cache, or a Handlebars template reading the wrong product field. We isolate whether it’s data (option sets / SKUs) or presentation (the theme template), fix the right layer, and confirm every variant resolves to the correct price and image.
My webhooks stopped firing or got deactivated, why?
BigCommerce deactivates a webhook after repeated non-2xx responses from your endpoint. So if order/created or product/updated stops reaching your system, the root cause is usually a slow or erroring endpoint, an SSL/timeout issue, or a payload your handler can’t parse. We check the webhook delivery history, fix the endpoint so it returns 200 fast, re-subscribe the events, and add retry handling so a single blip doesn’t kill the integration.
Can you fix it without breaking my live store?
Yes, that’s the whole point of the staging-first, Git-backed workflow. We never edit the live theme directly. Every theme fix is a new stencil push version you can roll back with one click, and we verify the fix against your exact symptom before handing it back. If anything regresses inside 14 days, we re-fix it free.
Not answered above?
Send the question as a brief; the answer comes back in writing within 24 hours, with a quote if it needs work.