How to Fix 429 Too Many Requests in Laravel: Throttle and Rate Limiting Done Right

php artisan route:list -v | grep throttle

If the 429 responses carry an X-RateLimit-Remaining header that bottoms out at exactly 60, you are hitting the default api limiter. The fix is to define your own limiter with a sane budget instead of accepting the default. In Laravel 11 and 12, you define named limiters in your application's bootstrap:

use Illuminate\Http\Request;
use Illuminate\Support\Facades\RateLimiter;
use Illuminate\Cache\RateLimiting\Limit;

// app/Providers/AppServiceProvider.php (or bootstrap/app.php)
RateLimiter::for('api', function (Request $request) {
    return Limit::perMinute(300)->by($request->user()?->id ?: $request->ip());
});

This raises the budget to 300 per minute and, crucially, keys it on the user ID when someone is logged in. IP-keyed limits are dangerous for authenticated users: one office behind a NAT gateway shares a single IP, and five employees can exhaust a guest budget before any one of them looks abusive.

Route::post('/webhooks/stripe', [WebhookController::class, 'store'])
    ->middleware('throttle:webhooks');

Route::get('/search', [SearchController::class, 'index'])
    ->middleware('throttle:search');

This is the same isolation principle behind good API design: if you are building endpoints that third parties will hit at unpredictable rates, it pays to design them as a proper custom REST API from the start 

->withMiddleware(function (Middleware $middleware) {
    $middleware->trustProxies(at: ['*']);
})

In production, never use at: ['*'] blindly — list your actual proxy addresses or CIDR ranges so clients cannot spoof X-Forwarded-For. Trusting the right proxies restores the real client IP, and your per-IP limits start working the way you intended.

CACHE_DRIVER=redis

With Redis the counters are atomic, fast, and shared across all servers. This one config change turns your rate limit from an estimate into an actual guarantee.

RateLimiter::for('api', fn (Request $request) => Limit::perMinute(60));

No reference to a limiter anywhere means no mystery errors. Run php artisan route:list -v after wiring everything up and read the middleware column line by line.

public function login(Request $request)
{
    $key = 'login:' . $request->ip() . '|' . strtolower($request->input('email'));

    if (RateLimiter::tooManyAttempts($key, 5)) {
        return response()->json([
            'message' => 'Too many attempts. Please try again later.',
            'retry_after' => RateLimiter::availableIn($key),
        ], 429);
    }

    if (! Auth::attempt($request->only('email', 'password'))) {
        RateLimiter::hit($key, 60);
        return response()->json(['message' => 'Invalid credentials.'], 401);
    }

    RateLimiter::clear($key);
    $request->session()->regenerate();

    return response()->json(['message' => 'Authenticated.']);
}

Four methods do all the work here: RateLimiter::hit records an attempt, tooManyAttempts checks the count, clear resets it after a successful login, and availableIn returns the seconds until the limit resets so you can feed a honest Retry-After to the client. Never reveal how many attempts were made or whether the account exists — a generic message plus retry timing keeps brute-force attackers from enumerating users. Apply the same discipline to password resets, registration, OTP resends, and email verification: these are the endpoints bots actually attack.

use Illuminate\Http\Exceptions\ThrottleRequestsException;

public function render($request, Throwable $exception)
{
    if ($exception instanceof ThrottleRequestsException) {
        Log::warning('Rate limit exceeded', [
            'ip' => $request->ip(),
            'url' => $request->url(),
        ]);

        return response()->json([
            'message' => 'Too many requests. Please slow down and try again.',
        ], 429, $exception->getHeaders());
    }

    return parent::render($request, $exception);
}

Logging every 429 with the IP and URL gives you the evidence trail you need. When a legitimate integration starts failing, you will see the pattern in minutes instead of guessing. And on the client side, respect the header: exponential backoff on 429 and 5xx responses is the difference between a retry that works and a retry storm.

for i in $(seq 1 70); do
  curl -s -o /dev/null -w "%{http_code} %{header_json} \n" \
    -H "Authorization: Bearer $TOKEN" \
    https://webixyhub.com/api/search?q=demo
done | sort | uniq -c

You are looking for the first 60 responses to be 200 and the 61st onward to be 429 with a Retry-After header present. If 429s arrive early, your key is wrong (check trusted proxies). If they never arrive, your limiter is not attached or your cache driver is array in a real environment.