Rate limits

Rate limits control the number of requests you can make to endpoints within a specific time window. These limits help ensure service stability and protect Roblox resources from abuse.

Discovery

There are two ways to determine rate limits: the reference documentation and response headers.

Documentation pages

Specific rate limits for each endpoint are under the Limits section on their documentation pages. View these sections to understand the rate limits that apply before making requests.

Response headers

Every API response includes headers that provide information about your current rate limit status.

HeaderDescription
x-ratelimit-limitThe total number of requests allowed within the rate limit window. This may include multiple limit values for different time windows.
x-ratelimit-remainingThe number of requests you can still make with your current authentication. When this reaches 0, you receive HTTP 429 responses.
x-ratelimit-resetThe number of seconds remaining until your rate limit quota resets to the full limit.

Here's an example of rate limit headers in an API response:


x-ratelimit-limit: 1000, 1000;w=60, 1000;w=60
x-ratelimit-remaining: 998
x-ratelimit-reset: 20

In this example:

  • You have 998 requests remaining out of your total limit.
  • Your quota will reset in 20 seconds.

Behavior

Rate limit behavior differs by authentication method and whether you make requests from within a Roblox experience.

API key

Rate limits for API keys are applied across all API keys per owner, which can be either a user or a group. These limits are enforced consistently regardless of where the requests originate—whether from HttpService, web applications, or other sources.

In-experience with HttpService

When calling endpoints in-experience using HttpService, requests also contribute to the fixed limit of 500 HTTP requests per minute per Roblox game server. See In-experience HTTP requests for more details.

OAuth 2.0

OAuth 2.0 rate limits are applied per access token. Since each access token represents a unique combination of user and application, every user using your app receives their own independent rate limit quota.

Handling rate limits

Write your code to expect and handle HTTP 429 (Too Many Requests) responses due to documented limits, abuse prevention, or high-load scenarios. When rate limited, check the retry-after response header as a guideline for when to retry. If there is no retry-after response header present, implement an exponential backoff retry strategy.