Detecting Cart & Inventory-Hoarding Bots

When a limited product drops, the enemy is not always the checkout fraudster. Often it is the hoarding bot: automation that slams add-to-cart on scarce SKUs, holds the reserved inventory, and either resells access, flips the items, or simply denies your real customers a fair shot. Depending on how your store reserves stock, a wave of these can make a fully stocked drop look sold out within seconds. This tutorial covers how to detect the pattern and the enforcement levers that actually break it.

How cart hoarding works

The mechanics are simple, which is why the abuse is so common:

1. A bot monitors your product or collection page for a SKU going live or a "sold out" flipping to available.
2. The instant it does, the bot fires add-to-cart requests, often for the maximum allowed quantity, across many parallel sessions.
3. Depending on your store setup, that inventory is now reserved to those carts.
4. The bot never completes checkout, or completes only the most profitable subset, leaving the rest of the stock frozen until reservations expire.

The damage is not just lost sales. It is the customer-experience wreckage of a drop that appears to sell out instantly while real fans watch empty carts, followed by items reappearing minutes later when reservations lapse.

Detection signals

Hoarding bots leave fingerprints. Watch for these, especially in the minutes around a scheduled drop:

• Add-to-cart velocity far above baseline. A single session or IP generating dozens of add-to-cart events per minute is not shopping; it is scripting.
• Cart-to-checkout ratio collapse. In normal traffic a healthy share of carts progress toward checkout. During an attack you see a flood of add-to-cart with almost no corresponding checkout starts.
• Uniform request timing. Humans hesitate. Bots fire on near-perfect intervals. A histogram of inter-request times that spikes at a single value is a giveaway.
• Concentrated origins. Bursts from datacenter IP ranges, a narrow set of subnets, or rotating addresses that all share a device fingerprint.
• Instant reaction to availability. Add-to-cart events landing within milliseconds of a SKU becoming available, faster than any human could click.
• Max-quantity behavior. Repeated attempts to cart the maximum allowed quantity of the scarcest items.
• Headless and automation tells. Missing or inconsistent browser signals, navigator.webdriver flags, and fingerprints that do not match any real device profile.

Any one of these can occur innocently. Several together, clustered in a drop window, are the signature of hoarding.

Enforcement lever 1: cart TTL

The most direct counter to hoarding is a cart time-to-live: stock is not held indefinitely just because it sits in a cart. The tighter the reservation window, the less leverage a bot has.

• Shorten the reservation window during high-demand drops so unfinished carts release stock quickly back into the pool.
• Tie reservation to checkout progress, so serious buyers who advance keep their hold while idle carts expire fast.
• Communicate the window to real customers ("items are reserved for X minutes") so the pressure feels fair rather than punitive.

A short TTL does not identify bots, but it drastically limits the value of hoarding: inventory a bot grabs and sits on simply flows back to everyone else in short order.

Enforcement lever 2: rate limits

Rate limiting attacks the velocity signal directly. The goal is to cap how fast any single actor can grab inventory:

• Per-session and per-IP add-to-cart limits. Cap add-to-cart events within a rolling window. Set the ceiling well above genuine shopping behavior so real customers never hit it, but far below scripted velocity.
• Per-SKU quantity caps on the scarcest items, enforced server-side so client-side tampering cannot bypass them.
• Progressive throttling. Rather than a hard block, slow suspicious sessions so bots lose their speed advantage while borderline-legit users still function.

Rate limits are blunt on their own; combined with reputation and behavioral signals, they become precise.

Enforcement lever 3: reputation and behavioral filtering

Velocity and TTL controls are stronger when you can also reason about *who* is knocking. Filtering upstream removes much of the load before it ever touches your cart:

• Block datacenter IPs, VPN, proxy, and Tor exit nodes that carry disproportionate bot traffic during drops.
• Geo-fence if a drop is regional and you see abuse from countries you do not serve.
• Fingerprint automation so headless and scripted sessions get challenged or blocked regardless of which IP they rotate to.

This is where Shieldy Fraud Filter fits into a drop-defense stack. Its bot detection and IP/country/VPN/proxy/Tor blocking cut off the automated traffic before it can flood your add-to-cart endpoint, so your TTL and rate-limit rules only have to handle the residual that slips through. Fewer bot requests reaching the cart means fewer false-positive risks for real fans too.

A drop-day playbook

Put it together into an operational routine:

1. Before the drop: tighten cart TTL, confirm per-SKU quantity caps, and make sure reputation filtering is active for the SKUs going live.
2. At launch: watch add-to-cart velocity and the cart-to-checkout ratio in real time. A collapsing ratio is your earliest alarm.
3. During: let rate limits and progressive throttling absorb spikes; escalate blocking on origins showing clear bot signatures.
4. After: review the logs. Which IP ranges, fingerprints, and timing patterns showed up? Feed that back into your rules for the next drop.

Measuring success

You will know it is working when:

• The cart-to-checkout ratio during drops looks closer to normal traffic.
• "Sold out in seconds, then restocked" complaints drop off.
• Sell-through on limited items goes to real, distinct customers rather than a handful of high-velocity sessions.

Hoarding bots exploit the gap between reserving stock and paying for it. Close that gap with a short TTL, cap velocity with rate limits, and filter the automated traffic before it arrives. If you want the filtering layer handled for you ahead of your next launch, pick a plan that fits your volume and have it running before the timer hits zero.