How This Dev Bypassed LVR's Rate Limits and Cleaned Full Stock

Most bots hit the same wall on LVR drops.

20 add-to-cart requests per product. Then a 60-second timeout. Game over.

While everyone else watched restocks trickle out in slow waves, one developer found a button that changed everything.

A button that nobody was looking at.

A button that bypassed every single rate limit.

Here's how Shinobi cleaned full stock on multiple LVR releases — and why this discovery rewrote the playbook for e-commerce automation.

The Problem: LVR's Iron Grip on Add-to-Cart

If you've ever tried to bot LVR (LUISAVIAROMA), you know the pain.

Their rate limiting was brutal:

• Global limits set per PID (Product ID)
• ~20 "Add to Cart" requests = instant 60-second cooldown
• Restocks sold out in waves, not bursts
• Traditional bots couldn't keep up

Developers would optimize their requests, rotate proxies, and still watch stock slip away during those forced cooldowns.

Everyone accepted this as the cost of doing business.

Until someone clicked on a button that nobody else was paying attention to.

The Discovery: One Button to Rule Them All

Picture this: You're reverse-engineering LVR's checkout flow for the hundredth time. Same endpoints. Same limitations. Same frustration.

Then you notice something tucked away in the UI:

"Send a Gift"

Innocent enough, right?

Wrong.

That button was the key to everything.

await fetch("https://www.luisaviaroma.com/myarea/api/sendagift/generate", {
    headers: {
        accept: "*/*",
        "accept-language": 
            "en,it-IT;q=0.9,it;q=0.8,en-US;q=0.7,de;q=0.6,eu;q=0.5,ru;q=0.4,pl;q=0.3",
        "cache-control": "no-cache",
        "content-type": "application/json",
        pragma: "no-cache",
        "sec-ch-ua": 
            '" Not A;Brand";v="99", "Chromium";v="90", "Google Chrome";v="90"',
        "sec-ch-ua-mobile": "?0",
        "sec-fetch-dest": "empty",
        "sec-fetch-mode": "cors",
        "sec-fetch-site": "same-origin",
        "x-lvr-requested-with": "sendagift/generate",
        "x-requested-with": "XMLHttpRequest",
    },
    referrer: 
        "https://www.luisaviaroma.com/myarea/sendagift/generate?ItemCode=73I-
IUT025&EncodedVendorColorId=MjcwNQ2",
    referrerPolicy: "strict-origin-when-cross-origin",
    body: JSON.stringify({
        IsMobile: false,
        ItemCode: productJson.ItemKey.ItemCode,
        EncodedVendorColorId: this.chosenSize.EncodedVendorColorId,
        RecipientName: "tony",
        RecipientEMail: "iguessidontlikesurprises@dot.com",
        SenderMessage: null,
    }),
    method: "POST",
    mode: "cors",
    credentials: "include",
}
);

Here's what happened when I clicked it:

• Different endpoint entirely
• No /myarea/bag/add request
• Completely separate API route
• Same result: item added to cart

My heart rate doubled. This was it.

Why This Works: The Backend Logic Nobody Talks About

Let me break this down so it clicks instantly.

In most backend architectures:

• Different API routes = different controllers
• Different controllers = different rate limit buckets
• Different buckets = fresh limits

Think of it like having two doors to the same room. If one door has a bouncer checking IDs and limiting entry, what happens if you find a side door with no bouncer?

You walk right in.

That's exactly what the "Send a Gift" endpoint was — a side door with no rate limiting.

The technical breakdown:

• Normal ATC: /myarea/bag/add → Rate limited after 20 requests
• Gift ATC: /sendagift/generate → No rate limits applied
• Result: Unlimited add-to-cart requests through the gift flow

The Plot Twist: Emails Were Never the Plan

Here's where it gets interesting.

Using "Send a Gift" normally triggers an email to the recipient with a claim link. Not exactly ideal when you're trying to checkout at light speed.

But here's what I discovered in the response body:

{
"Error":"None",
"ErrorDescription":null,
"Token":"TFU1YW1qNmVEelVBMzNXaUhpckIrSXdLeGFzL0Q5SGFhK1A0bHRkZVU0UT01",
"AcceptUrl":"https://www.luisaviaroma.com/myarea/sendagift/accept/TFU1YW1qNmVEelVBMzNXaUhpckIrSXdLeGFzL0Q5SGFhK1A0bHRkZVU0UT01?ColorId=MjAw0"
}

See that token property?

That's the exact same token that gets emailed to recipients.

No email extraction needed. No inbox monitoring. Just pure, raw access to the claim link directly from the API response.

The Implementation: From Discovery to Domination

Here's how Shinobi implemented this bypass:

Step 1: Hit the gift endpoint instead of regular ATC

// Instead of: /myarea/bag/add
// Use: /sendagift/generate

Step 2: Extract the token from response

• Parse the JSON response
• Grab the token value
• Skip the entire email flow

Step 3: Accept the gift programmatically

• Use the token to claim the item
• Item lands in cart instantly
• Proceed to checkout

The result? While other bots waited out 60-second cooldowns every 20 items, Shinobi was adding hundreds of items per minute with zero restrictions.

Why This Matters: The Bigger Picture

This isn't just about one exploit on one site.

It's about how we think about automation and security:

1. Alternative endpoints are everywhere Most sites have multiple ways to achieve the same action. Gift flows, wishlist transfers, quick-buy options — each might have different rate limiting.

2. Developers focus on the obvious Everyone was so focused on optimizing the main ATC endpoint that nobody thought to check alternatives. The best exploits hide in plain sight.

3. Rate limits are often inconsistent Companies apply rate limits to high-traffic endpoints but forget about lesser-used features. This creates massive opportunities.

The Lessons: What You Can Learn From This

Always explore alternative flows:

• Gift options
• Wishlist features
• Mobile-specific endpoints
• Legacy API routes

Check every button: That random "Email to Friend" button? The "Save for Later" option? Each one might reveal a new endpoint with different rules.

Response bodies tell stories: Don't just look at success/failure. Examine every field in the response. You never know what tokens or data might be hiding there.

Think like a backend developer: Understanding how rate limits are typically implemented helps you spot where they might be missing.

The Aftermath: What Happened Next

Once word got out about the gift button bypass, the game changed:

• Shinobi users cleaned multiple releases completely
• Stock that usually lasted 30 minutes sold out in 2
• Other bot developers scrambled to implement similar logic
• LVR eventually patched the vulnerability (but it took months)

But here's the thing: This pattern repeats across e-commerce.

While everyone fights over the front door, the side doors remain wide open.