Rate Limit
Better Auth includes a built-in rate limiter to help manage traffic and prevent abuse. By default, in production mode, the rate limiter is set to:
- Window: 60 seconds
- Max Requests: 100 requests
You can easily customize these settings by passing the rateLimit object to the betterAuth function.
In addition to the default settings, Better Auth provides custom rules for specific paths. For example:
"/sign-in/email": Limited to 3 requests within 10 seconds.
In addition to that, plugins also define custom rules for specific paths. For example, twoFactor
plugin has the following custom rules:
- "/two-factor/verify": Limited to 3 requests within 10 seconds.
These custom rules ensure that sensitive operations are protected with stricter limits.
Configuring Rate Limit
Rate Limit Window
Storage
By default, rate limit data is stored in memory. However, you can either use your database or custom storage to store rate limit data.
Using Database
make sure to run migrate
to create the rate limit table in your database.
Custom Storage
Handling Rate Limit Errors
When a request exceeds the rate limit, Better Auth returns the following header:
X-Retry-After
: The number of seconds until the user can make another request.
To handle rate limit errors on the client side, you can manage them either globally or on a per-request basis. Since Better Auth clients wrap over Better Fetch, you can pass fetchOptions to handle rate limit errors
Global Handling
Per Request Handling
Schema
If you are using a database to store rate limit data you need this schema:
Table Name: rateLimit
Field Name | Type | Key | Description |
---|---|---|---|
key | string | Unique identifier for each rate limit key | |
window | integer | - | Time window in seconds |
max | integer | - | Max requests in the window |
count | integer | - | Number of requests made in the window |