A flash sale with no quantity guardrails hands your discounted stock to whoever automates fastest. The fix is a cap, and the whole skill is sizing it — high enough that the offer still feels generous, low enough that one buyer cannot clear the run. This covers how to pick that number, why the cap should expire with the sale, and the checks that decide whether the cap is real or decorative.
What actually goes wrong
Three failures, and they are not equally likely.
One buyer takes the lot. The classic. A reseller with a script clears the discounted stock in the first minutes, and the sale you ran to reach many customers reached one. You get the revenue at a discount and none of the customers.
Stock goes negative. Concurrent checkouts on limited inventory oversell, and you are cancelling orders during the promotion you ran to build goodwill.
Margin disappears quietly. Nobody did anything wrong. The discount was simply bigger than the volume justified, and the sale lost money that nothing flagged.
A cap addresses the first two. The third is arithmetic, and worth doing before the sale rather than after.
Sizing the cap
Start from what a real customer would buy, not from what a reseller would.
Look at your normal order quantity for the product. If most orders are one or two, a cap of three is generous to everyone genuine and useless to anyone buying to resell. If people routinely buy six, a cap of three is a tax on your best customers.
Two adjustments:
- Gifting seasons need headroom. A cap that works in March can be wrong in December, when one person legitimately buys five of the same thing.
- Cheap items need higher caps. A £4 product capped at two reads as mean. The reseller risk is lower anyway, because the margin per unit is not worth their effort.
The number to avoid is one. "Limit 1 per customer" on anything that is not genuinely one-per-household reads as distrust, and it makes a normal purchase feel policed.
Per order, or per customer?
A per-order cap stops one big order. A determined buyer places four small ones.
For a flash sale on stock you can replenish, per-order is usually enough — the friction alone deters most of it and the cap expires in hours anyway. For genuinely limited stock, you need the count to cross orders, which means a per-customer cap and therefore a customer account.
The tradeoff is real: requiring an account during a flash sale costs conversions from people who would have checked out as guests. For a large discount on scarce stock it is worth it. For 10% off a restocked line it is not.
The cap has to end when the sale does
This is the failure that outlives the promotion.
A cap set for a weekend and not removed is still there in November, quietly blocking a wholesale customer from ordering more than three of something. Nobody notices, because the failure looks like a customer choosing not to buy more.
So: set the end time when you set the cap, in the same action. If the tool supports scheduled rules, use them. If not, put a calendar reminder in before the sale starts rather than after it ends, because the after-sale period is exactly when nobody is looking at rules.
Worth also scheduling the start. A cap that goes live an hour before the sale costs nothing; one applied ten minutes late has already missed the traffic spike that made it necessary.
Say the limit up front
A cap discovered at checkout, during a time-limited sale, is the worst possible sequencing: the shopper is rushing, they have made a decision, and you are refusing them.
Stated on the product page — "Limit 3 per customer during this sale" — it does the opposite. It sets expectation, signals that stock is genuinely limited, and tells honest buyers the sale is designed for them rather than for bulk buyers. On a scarce product that message helps the sale rather than dampening it.
Making sure the cap is real
A cap enforced in the theme is not a cap. During a flash sale, the people you are trying to stop are exactly the people who will use a cart permalink.
Test before the sale, not during:
- Build a permalink that exceeds the cap —
yourstore.com/cart/VARIANTID:10for a cap of three. - Open it and try to check out. Blocked with your message means the rule is real.
- If you use a per-customer cap, place a second order from the same account rather than one big one.
- Check a dynamic checkout button too, which takes the buyer from the product page straight past the cart.
If your rules once ran on Shopify Scripts, note that they stopped executing on 30 June 2026. A flash sale is a costly time to discover that.
Bots, and what a cap does not solve
A cap is a rule about quantity. It is not a defence against automation, and the two get conflated.
A script that can place one order can place five, each under the cap, from five accounts created that morning. If your problem is genuinely automated buying rather than enthusiastic customers, the cap is one layer and not the load-bearing one.
What actually helps, roughly in order of effort:
- Require an account, created before the sale. An account age requirement is far more annoying to automate around than a cap, because it cannot be satisfied at purchase time.
- Do not publish the exact drop time, or add a random delay. Most automation is scheduled.
- Shopify's own bot protection on checkout, where available on your plan.
- A queue for genuinely high-demand drops, which solves distribution properly rather than rationing after the fact.
Be honest about which problem you have. Most stores that think they have a bot problem have a popularity problem, where a cap is exactly the right tool. Stores that genuinely have a bot problem will not fix it with a limit, and spending the planning time on the cap instead of the queue is the mistake.
The arithmetic nobody does
A cap protects distribution. It does not make a bad discount good.
Before the sale, work out the volume at which the discount pays. If your margin is 40% and you discount 25%, you are keeping 15 points and need roughly 2.7 times the units to hold the same gross profit. If you do not expect that, the sale is buying something else — customer acquisition, clearance, attention — and it is worth being honest about which, because the success metric changes with it.
Then check the interaction with everything else running. A flash sale on top of a volume discount and a customer's own code can compound into a price nobody modelled. Build the worst-case cart before the sale and look at the total.
Setting it up
- Size the cap from your normal order quantity, not from the reseller risk.
- Choose per-order or per-customer based on whether the stock is replenishable.
- Schedule start and end together.
- State it on the product page.
- Test with a permalink before the sale opens.
- Model the worst-case stacked cart.
With Limit, scheduled rules and per-customer caps are on the $9.99 plan, and checkout enforcement is on every plan including the free one.
Where to go next
If the limit needs to survive beyond the sale — allocated stock, a permanent two-per-customer rule — lifetime and time-window caps is the relevant piece. For scopes, multipliers and enforcement generally, see the MOQ guide.
