When your apps throttle you: API rate limits and the flash-sale failures nobody plans for

Your store stayed up during the flash sale. Checkout worked. Orders came through. By every metric you're watching, the sale was a success.

Then, three days later, a customer emails asking why they never got their loyalty points. Another asks why their review never posted. Your inventory sync shows 40 units of a product that actually sold out on day one. Nothing crashed. Nothing looked broken. But somewhere in the middle of your traffic spike, a piece of your stack quietly stopped doing its job, and nobody noticed because there was no error message on your screen, just a queue that never got worked through.

Two different kinds of failure that look identical from the outside

Store owners tend to think about flash-sale risk in terms of server capacity: can the site handle the traffic, will checkout hold up, is the CDN caching properly. That's a real concern, and it's covered well elsewhere, including in traffic spikes of 500 percent in 30 minutes.

But there's a second, less visible category of risk: the apps bolted onto your store each have their own backend, their own API, and their own rate limits, set by the app vendor, not by you. A Shopify app rate limit is usually expressed as a number of API calls per second or per minute, often on a leaky-bucket model where you get a burst allowance and then a steady refill rate. WooCommerce plugins that call external services (a loyalty platform, a review aggregator, a tax calculator) inherit that same constraint from whatever API they depend on, and BigCommerce apps work the same way.

When your traffic is normal, these limits are invisible. Your store generates a trickle of API calls and the app's backend handles them without breaking a sweat. When traffic spikes 10x for two hours during a flash sale, that trickle becomes a flood, and the app hits its ceiling. What happens next depends entirely on how well the app was built, and that's the part most store owners never think to check.

Where third-party app throttling actually shows up

App performance during sales tends to degrade in a few predictable places, because these are the integrations that scale their API calls directly with order volume rather than with page views.

Loyalty and rewards apps award points per completed order. If the app's API queue backs up, points get delayed by hours or, in some implementations, dropped entirely if the retry logic gives up too early. Customers notice this immediately because loyalty balances are something they check.

Review request and review display apps often call out to a third-party service on every order confirmation to schedule a review request email. Under load, some of these calls simply time out and are never retried, meaning a chunk of your best customers, the ones who bought during your biggest sale, never get asked for a review.

Inventory sync apps that keep multiple sales channels in agreement (your store, a marketplace, a POS system) push stock updates via API on every sale. If those calls get throttled, your channels drift out of sync during exactly the window when accurate stock counts matter most. This compounds the kind of problem covered in [inventory counts that drift](/blog/inventory-counts-that-drift-why-your-channels-disagree-and-how-to catch-it), except it's triggered by success (a sales spike) rather than a random sync bug.

Shipping rate and tax calculation apps that call external APIs at checkout can also throttle, and when they do, some shoppers see a fallback rate, a blank field, or a stalled checkout step, similar in effect to the failures described in shipping rate calculator errors. Cart abandonment during a flash sale for a checkout glitch is a particularly bitter outcome, since it happens at your moment of maximum customer intent.

Why this failure mode is so hard to catch

Rate limiting is designed to fail quietly. A well-built app doesn't crash when it hits its API ceiling, it queues the request, retries with backoff, or silently drops it after a set number of attempts. None of that generates a 500 error on your storefront. Your uptime monitor, if you have one, sees a healthy site the entire time, which is a good reminder that uptime and full functionality are not the same thing (see uptime monitors, status pages, and pingers for the distinction).

Most app dashboards don't surface throttling events prominently either. You'd need to dig into the app's own logs, which many merchants never look at outside of initial setup, or you'd need the app vendor to proactively email you, which not all of them do. The result is a failure that surfaces days later, in a support ticket, a mismatched inventory count, or a customer complaint, long after the sale is over and the root cause is hard to trace back.

What to actually do before your next sale

Start by identifying which of your installed apps make API calls that scale with order volume rather than with page views. Loyalty, reviews, inventory sync, personalized recommendations, and some shipping and tax integrations are the usual suspects. Apps that only affect the storefront's static appearance (theme customizers, most popups) are lower risk here.

For each high-risk app, check its documentation or support resources for stated rate limits and what happens when they're exceeded. Shopify's app developer documentation, WooCommerce's REST API docs, and BigCommerce's API reference all publish rate-limit behavior for their platform APIs, and reputable third-party apps should be able to tell you their own thresholds and retry behavior if you ask support directly. If a vendor can't answer this question, treat that as useful information in itself.

During the sale, or in a load test beforehand, watch for delayed side effects rather than just page load times: does the loyalty points balance update within a reasonable window after an order, does a test review request arrive, does inventory across channels stay in sync. The playbook in how to load test your store before a flash sale covers the server-capacity side of this preparation; app throttling deserves the same deliberate test pass.

After the sale, reconcile: pull a sample of orders from the peak traffic window and manually verify that every downstream action fired correctly. It's tedious, but it's the only way to find a silent failure before a customer finds it for you. This is also where continuous monitoring earns its keep. Cassian™ tracks order flow, stock levels, and site health around the clock, so if inventory sync or checkout behavior drifts during a spike, you get an alert instead of a support ticket three days later. The Cassian Score™ summarizes that health at a glance, which matters most on exactly the days when you have no spare attention to go digging through app logs.

The takeaway

A flash sale succeeding at the checkout level doesn't mean every part of your stack kept up. The apps that handle loyalty, reviews, inventory sync, and shipping calculations each have their own ceiling, set by someone else's infrastructure, and that ceiling has nothing to do with how well your store's server performed. The fix isn't paranoia, it's a short list of questions to ask your app vendors before your next big sale, and a monitoring habit that watches what happens after checkout, not just whether the page loaded.