# SlowAPI: rate limiting for FastAPI and Starlette, built on flask-limiter and limits > SlowAPI is a thin adapter that brings flask-limiter's rate limiting model to Starlette and FastAPI. It delegates the actual counting to the limits library, adds a decorator interface, and carries a documented constraint that every rate-limited endpoint must accept `request: Request` as a named argument. **laurentS/slowapi** — A rate limiter for Starlette and FastAPI - Repository: https://github.com/laurentS/slowapi - Website: https://pypi.org/project/slowapi/ - Stars: 2,069 · Forks: 131 - Language: Python - License: MIT - Published: 2026-10-11 · Updated: 2026-10-11 · Language: en - Canonical page: https://hysenlabs.com/projects/laurents-slowapi ## SlowAPI delegates the counting to the limits library and adds a decorator layer on top SlowAPI is not a rate limiting engine on its own. Actual counting is done by the limits library, and SlowAPI adds the ASGI integration layer that connects those counts to Starlette and FastAPI routes. The credits section puts it plainly: SlowAPI is "a (still partial) adaptation to Starlette and FastAPI" of flask-limiter, and "the actual rate limiting work is done by limits." The pyproject.toml pins this dependency at `limits = ">=2.3"`, so any version of the limits library from 2.3 onward satisfies the constraint. That design has a practical consequence for troubleshooting. When a limit fires unexpectedly or a backend behaves oddly, the problem may sit in limits rather than in SlowAPI. Both repositories maintain their own issue trackers and release cycles separately. A FastAPI team adopting SlowAPI takes on two dependencies, and backend behavior for redis or memcached is documented in limits, not here. Adapting from flask-limiter also means the feature set reflects what flask-limiter covers, minus whatever the port has not yet carried over. "Most features are coming from FlaskLimiter and the underlying limits" is how the project describes its own scope, and the word "most" is the one to weigh when comparing behavior you know from a Flask project. ## Installing slowapi and applying a first rate limit decorator SlowAPI is on PyPI and installs with one command. ```bash pip install slowapi ``` Rate limits are written as strings in a decorator applied to endpoint functions. The correct form, as given in the README, requires `request: Request` as a named argument: ```python @limiter.limit("5/minute") async def myendpoint(request: Request) pass ``` The limit string format follows what the limits library accepts; "5/minute" is the example in the README. A single endpoint can carry multiple limit decorators when more than one rule is needed, which is a supported feature. For development and contributions, the repository uses poetry to manage its dependencies. Running `poetry install` from the repository root brings in the full set of development tools listed in pyproject.toml, including pytest, black, flake8, mypy and httpx. ```bash poetry install ``` Running the test suite requires one command. ```bash pytest ``` Those are the only documented setup steps for a contributor working on the library. ## The request argument must appear in the function signature, or the limit does nothing Every endpoint carrying a rate limit decorator must accept `request: Request` as a named argument, or SlowAPI cannot hook into the request and the limit will not take effect. This is documented under "Limitations and known issues" with both the correct and incorrect form shown side by side. For an existing FastAPI project with many routes, adding rate limits means auditing each endpoint you plan to limit and updating its signature before applying the decorator. No fallback behavior is documented for this case. FastAPI allows endpoint functions that do not accept the `request` object at all, and those functions still process requests normally. A limit decorator added to such an endpoint without a corresponding signature update does not produce a documented error, meaning the rate limit simply does not activate. That behavior makes the signature requirement easy to overlook during code review. ## Redis, memcached and memory are the three listed backends, with redis as an optional extra Three backends cover the storage options: redis, memcached and memory. Memory is the fallback and needs no extra dependencies beyond the base install. Redis is marked as an optional dependency in pyproject.toml under the `redis` extras key, with the client pinned at `^3.4.1`. That pin matters before enabling the redis backend. The `^3.4.1` constraint requires the redis 3.x Python client. Whether a deployment has already upgraded that client beyond the 3.x line is a detail to check before reaching for the redis backend. Memcached is listed as a supported option without separate configuration detail in the README. For backend configuration beyond the names listed, the documentation at slowapi.readthedocs.io is the appropriate source. Memory as the fallback means development and testing can proceed without running any external service. Whether memory is acceptable for production is a question the limits library documentation addresses, not the SlowAPI README. ## Shared limits apply one rule across a group of routes, and sync and async endpoints both work Beyond per-endpoint decorators, SlowAPI supports shared limits: a single limit definition that applies across a set of routes rather than to each one independently. This feature appears in the supported list without a configuration example in the README body. Configuration details live at slowapi.readthedocs.io. Both sync and async HTTP endpoint functions are covered. The project's stated goal is to support all currently supported Python versions, and the feature list includes both endpoint types explicitly. One caveat is attached to async support in the README: there "might be some API changes when changing the code to be fully async," and semver will signal those changes when they arrive. Version 0.1.10 is not the fully async form. Teams planning a long-lived dependency on SlowAPI should track the changelog for the version bump that marks the async API change. ## WebSocket endpoints are unsupported, and the async rewrite signals a future API break Two explicit limitations appear under "Limitations and known issues." The first, the request argument requirement, is covered above. WebSocket endpoints cannot be rate-limited with SlowAPI; they are listed as "not supported yet," with no version or milestone given. For a FastAPI application that serves both HTTP and WebSocket routes from the same process, rate limiting covers only the HTTP side. No workaround is documented for the WebSocket gap. The pending full-async rewrite adds a separate concern about stability. Semver will carry the signal for the breaking change, and the README commits to that communication path. Teams that pin dependencies and review changelogs before upgrading are in a better position, because this specific change is announced as coming rather than hinted at. A floating version constraint on SlowAPI means accepting an API break when the async migration completes. ## pyproject.toml version floor is 3.7 while the project targets only currently supported Python The pyproject.toml specifies `python = ">=3.7,<4.0"` as the version constraint. At the same time, the README states that "the library aims to support all currently supported versions of python" and links to the Python developer guide to define that set. These two claims do not agree. The Python developer guide defines the currently supported range, and 3.7 is not in it. The pyproject.toml constraint does not enforce the supported-version boundary the README describes, so a team installing SlowAPI on an older interpreter will encounter no install error even if that interpreter is past its end of life. A team starting fresh should check the Python developer guide directly to see which versions fall inside the active support window, since the package constraint alone does not answer that question. ## flask-limiter is the direct source and the right choice for WSGI Flask applications SlowAPI describes its relationship with flask-limiter directly in the README and in the credits: it is an adaptation of flask-limiter to Starlette and FastAPI, and the limits library is the shared dependency that both use for counting. Rate limit string syntax and backend support come from the same place in both libraries. What differs is the framework layer. flask-limiter targets WSGI Flask applications. SlowAPI targets ASGI applications through Starlette, which is the foundation FastAPI builds on. A Flask application with existing flask-limiter configuration cannot port that configuration directly to SlowAPI, because middleware attachment and decorator registration work differently between the two. Choosing between them usually follows the framework choice. Flask projects have flask-limiter as the established option. FastAPI and bare Starlette applications have SlowAPI as the documented ASGI port. That the adaptation is described as "still partial" means some flask-limiter features have not been carried over, and the readthedocs documentation is where to check which ones matter for a specific case. ## Conclusion SlowAPI is suitable for FastAPI and Starlette applications that need per-route rate limiting without building the accounting layer from scratch. It is not suitable for projects where WebSocket rate limiting is required, since that is explicitly unsupported as of v0.1.10. Before adopting, audit every endpoint you plan to limit and confirm it accepts `request: Request` as a named argument, because the limit silently does nothing without it. Check the pyproject.toml version constraint against your Python version, and review the redis client pin at `^3.4.1` if you plan to use the redis backend. ## FAQ ### What is SlowAPI? SlowAPI is a rate limiting library for Starlette and FastAPI adapted from flask-limiter. It wraps the limits library, which handles the actual counting, and exposes a decorator interface for applying limits to endpoint functions. ### How do I install SlowAPI? Run `pip install slowapi` to add the base package. Using the redis backend requires the optional redis extra, which the pyproject.toml defines under the `redis` extras key. ### What backends does SlowAPI support? Three backends are listed: redis, memcached and memory. Memory is the fallback and needs no extra dependencies. Redis is an optional extra pinned at `^3.4.1`. ### Can SlowAPI rate-limit WebSocket endpoints? No. WebSocket endpoints are explicitly listed under known limitations as not yet supported. No workaround is documented. ### What is the difference between SlowAPI and flask-limiter? SlowAPI is an adaptation of flask-limiter for ASGI frameworks, specifically Starlette and FastAPI. flask-limiter targets WSGI Flask applications. Both use the limits library for counting, but the middleware and decorator registration differ. ## Sources - [laurentS/slowapi on GitHub](https://github.com/laurentS/slowapi) - [License: MIT](https://github.com/laurentS/slowapi/blob/master/LICENSE) - [Project website](https://pypi.org/project/slowapi/) - [README](https://github.com/laurentS/slowapi/blob/master/README.md) - [Releases](https://github.com/laurentS/slowapi/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/laurents-slowapi