General Configurations
boolean
default:"true"
Enable or disable the plugin.
Database Configurations
string
required
The token to authenticate with the Upstash Redis REST API. You can find this
credential on Upstash Console with the name
UPSTASH_REDIS_REST_TOKENstring
required
The URL for the Upstash Redis REST API. You can find this credential on
Upstash Console with the name
UPSTASH_REDIS_REST_URLstring
default:"@strapi"
The prefix for the rate limit keys. The plugin uses this prefix to store the
rate limit data in Redis.
For example, if the prefix is
For example, if the prefix is
@strapi, the key will be
@strapi:<method>:<route>:<identifier>.boolean
default:"false"
Enable analytics for the rate limit. When enabled, the plugin extra insights
related to your ratelimits. You can use this data to analyze the rate limit
usage on Upstash Console.
Strategy
The plugin uses a strategy array to define the rate limits per route. Each strategy object has the following properties:('GET' | 'POST' | 'DELETE' | 'PUT' | 'PATCH' |'ALL')[]
required
An array of HTTP methods to apply the rate limit.
For example,
For example,
["GET", "POST"]string
required
The path to apply the rate limit. You can use wildcards to match multiple
routes. For example,
Some examples:
* matches all routes. Some examples:
path: "/api/restaurants/:id"path: "/api/restaurants"
string
required
The source to identifiy the user. Requests with the same identifier will be
rate limited under the same limit.
Available sources are:
Available sources are:
ip: The IP address of the user.header: The value of a header key. You should pass the source in theheader.<HEADER_KEY>format.
For example,header.Authorizationwill use the value of theAuthorization
string
Enable debug mode for the route. When enabled, the plugin logs the remaining
limits and the block status for each request.
object
required
The limiter configuration for the route. The limiter object has the following
properties:
'fixed-window' | 'sliding-window' | 'token-bucket'
required
The rate limit algorithm to use. For more information related to algorithms, see docs here.
fixed-window: The fixed-window algorithm divides time into fixed intervals. Each interval has a set limit of allowed requests. When a new interval starts, the count resets.sliding-window: The sliding-window algorithm uses a rolling time frame. It considers requests from the past X time units, continuously moving forward. This provides a smoother distribution of requests over time.token-bucket: The token-bucket algorithm uses a bucket that fills with tokens at a steady rate. Each request consumes a token. If the bucket is empty, requests are denied. This allows for bursts of traffic while maintaining a long-term rate limit.
number
required
The number of tokens allowed in the time window.
string
required
The time window for the rate limit. Available units are
For example,
"ms" | "s" | "m" | "h" | "d" For example,
20s means 20 seconds.number
The rate at which the bucket refills. This property is only used for the token-bucket algorithm.