---
title: Rate limit policy
description: Understand and implement SuperTokens rate limit policies for managed and self-hosted services.
sidebar:
  order: 3
---

## Overview

The following page describes how rate limits apply during SuperTokens API calls.

## For managed service

The SuperTokens core of a managed account is rate limited on a per app and per IP address basis.
This means that if you query the core for `app1` using the same IP address, the rate limit kicks in, and you get a `429` status code back from the core.
However, if you query the core using different IP addresses or for a different app, the rate limit of that does not interfere with the previous requests (that had another IP or was for another app).

### Free tier
The free tier of the managed service has a rate limit of 50 requests per second with a burst of 50 requests per second (with no delay).
This should be enough for 5-10 concurrent sign in / up (each sign in API call queries the SuperTokens core multiple times).

:::note[The backend SDK auto retries if it gets a `429` status code from the core (up to 5 times before throwing an error).]
:::

### Paying users
If you are a paying user for SuperTokens, the rate limit and the burst limit adjust dynamically based on your usage (with a minimum of a 100rps).
You should not see any `429`s unless there is a **significant** spike in requests.

:::info[Paid Feature]
If you want higher rate limits, please [email support](mailto:support@supertokens.com), requesting a higher rate limit.
:::

### Special case
The `/hello` API exposed by the core is commonly used for health checks.
This API does not require any API key, and has its own rate limit of 5 requests per second per app (regardless of the IP address querying it).
This is independent to the rate limit described above, and cannot change.

## For self hosted

The SuperTokens core has no rate limit other than for the `/hello` API (which is 5 requests per second per app).
You are free to add rate limits to the core by using [a reverse proxy like Nginx](https://www.nginx.com/blog/rate-limiting-nginx/).

If you want to implement rate limiting policy similar to the managed service described above, add the following to your `http` and `server` block in the `nginx.conf` file:

```text
http {
    # other configs..
    
    map $request_uri $limit_req_zone_key {
        "~^/(appId|appid)-(\w+)/?" $binary_remote_addr:$2;
        default $binary_remote_addr;
    }

    limit_req_zone $limit_req_zone_key zone=mylimit:10m rate50/s;
    limit_req_status 429;

    # other configs..

    upstream supertokens {
        server localhost:3567;
    }

    server {
        limit_req zone=mylimit burst=50 nodelay;

        # other configs..

        listen 0.0.0.0:80;

        location / {
            proxy_pass http://supertokens;
        }
    }
}
```

In the above, the core adds a rate limit per app per IP address.