Recent and Upcoming Changes to Roblox Web APIs

Hey developers,

This announcement is intended for developers who directly interact with the Roblox Web APIs. If you only use our Lua APIs such as HttpService, you only need to read “Dropping support for TLS 1.0 and TLS 1.1.”

As our platform evolves, we want to keep you informed about changes to our web API endpoints. We are making a number of changes to increase reliability, boost security, and standardize the way our public APIs behave. In order to minimize disruption, we are giving you advance notice for several of the changes and providing an opportunity to give feedback.

These changes will accelerate our move towards the Open Cloud application ecosystem, where we provide a rich set of APIs for developers to interact with Roblox.

If you have any questions or concerns, feel free to reply to this post and we will follow up.

Recent Changes

:closed_lock_with_key: Requiring HTTPS

In order to boost security, we have started requiring HTTPS (Hypertext Transfer Protocol Secure) across all our API endpoints.

Requests still using the HTTP protocol are now rejected with 400 status codes or redirected to HTTPS. Cookies will also include the secure attribute going forward, which prevents them from being attached to non-HTTPS requests.

Action Required: Please update any hardcoded URLs from http:// to https://

:cookie: Cookie Authentication

As a general rule, we recommend using your .ROBLOSECURITY cookies on the same IP address that you logged in on.

If this does not work for your use case, please submit a feature request for API endpoints you think that we should support with API Keys through the Open Cloud initiative.

Action Required: Update automation to use cookies from static IP addresses

:wave: Goodbye .RBXID Cookie

Many of the endpoints on required a special .RBXID cookie for authentication. In order to simplify our systems, we have stopped supporting that cookie.

Going forward the best practice for authentication is to use API keys with Open Cloud endpoints or the .ROBLOSECURITY cookie for other web endpoints that do not yet support API keys. Be aware that the .ROBLOSECURITY cookie is sensitive, and leaking it is almost as bad as sharing your password.

Action Required: None

Upcoming Changes

:city_sunrise: Sunsetting

As announced in Sunsetting, we are deprecating all endpoints on

Check out the announcement for a list of new endpoints you can upgrade to. If you cannot find replacement endpoints please let us know in the above thread.

Action Required: Upgrade any calls from to newer API endpoints by July 15, 2022

:sparkles: Unifying Standard Errors

If you are a prolific Roblox web developer, you may have noticed that the standard error responses vary quite a bit across different Roblox APIs for cases like:

  • 401 Unauthorized (User is not logged in)
  • 403 Token Validation Failed (Invalid XSRF token)
  • 429 Too Many Requests

In order to reduce complexity and provide a uniform experience for developers, we are going to unify the error responses.

Action Required: Update code that rely on the ‘Status Text’ matching specific strings, or error code being equal to 0 by August 1, 2022

Here are the upcoming standardized error responses. They will be gradually rolled out over the next few months, so your code may need to handle both the old and new responses for a few months.

Error Status Code and Status Text Response Body
:x: Invalid XSRF token 403 (Token Validation Failed) {“errors”:[{“code”:9001,“message”:“XSRF Token Validation Failed”}]}

(also returns ‘x-csrf-token’ header)
:question: User is not logged in 401 (Unauthenticated) {“errors”:[{“code”:9002,“message”:“Unauthenticated”}]}
:no_entry_sign: User is moderated 403 (Moderated User) {“errors”:[{“code”:9003,“message”:“Moderated User”}]}
:hourglass_flowing_sand: Throttling 429 (Too Many Requests) {“errors”:[{“code”:9005,“message”:“Too Many Requests”}]}

We recommend using the response body’s error code number (e.g. 9001) to differentiate between the errors. We do not provide any guarantee that the Status Text (e.g. Token Validation Failed) or response message will stay consistent over time for these standard errors.

:rocket: Dropping support for TLS 1.0 and TLS 1.1

As announced a few days ago, we are dropping support for TLS 1.0 and 1.1 from calls made via HttpService.

Action Required: Upgrade your external web services (if accessed by HttpService) to support TLS 1.2 or higher if accessed by July 5, 2022


This topic was automatically opened after 10 minutes.

In most cases we automatically redirect from http → https, but we want to encourage you not to rely on that behavior, since it can leave you susceptible to manipulator-in-the-middle attacks.


Thank you for the update!

I do have a question regarding concern within IP changes forcing cookie invalidation.

This change affects developers who use a VPS to host their services; with the requirements updated to ensure cookies are used on most endpoints, this is frustrating for developers. :confused:


Question is; How does it handle servers that do not necessarily have SSL certificates in them? Some of them just don’t allow you to connect to them without one. (HTTPS by default direct to port 443 of the servers, while HTTP direct to 80)

1 Like

This has been frustrating for me as someone who does automated testing with run-in-roblox with GitHub Actions. It’s still slow and unreliable even with a static IP workaround.

Ideally there would be an Open Cloud API which would let me run a script with access to the data model of an individual place and return the output to me. It would not save any changes to the place by default, but that might be a useful option to have.

I can’t submit a Feature Request because I don’t have permissions to post them.


As I posted previously,

can we get CORS accessibility for API endpoints, at least only for OpenCloud endpoints? It’s impossible to create websites that access Roblox APIs from the web without hosting your own infra or trustiong some CORS proxy provider that they’re not gonna harvest API keys.


First of all, great changes. I think these will make the platform a better place and all around more secure. However, there are a few issues that stand in the way of these changes.

Standard Errors

I belive changing errors to a standard format is something that has been needed for years. There is just SO many different error formats. (As someone who’s made Roblox API wrappers, this was something that ALWAYS annoyed me).

However, I do have a question: would it be possible to make all of the possible formats and error codes available on the docs page? If there’s going to be two possible formats that I have to check for with errors, I want to have a list of possible responses and error codes so I can make sure that I can cover everything.

For example, a not authorized response would include the old and new error response that our programs would have to be able to handle.

Even just a way to force the new/old errors. Being able to force opt-in would be really nice as well. Otherwise, there’s not really an easy way of handling this change, other than just spitting out a generic error is something goes wrong, which makes error handling impossible.

IP Locked Cookies

The new IP-locked cookies should be great for account security, and something that has been requested for years.

However, this does bring about a problem: running workflows that require cookies on a VPS or runner (like GitHub actions) will no longer work. An ideal solution for the time being is to allow us to create API keys which can function as cookies. Until all apis are supported by the Open Cloud API, we HAVE to use cookies, and so this change will prevent a lot of automated workflows and testing. Please consider this.


While these changes are great, I’m noticing a theme of neglecting to provide us with appropriate alternatives before removing features. Please add alternatives before you remove features.

I don’t want to be pessimistic - I just want to be able to use the API.


This has been brought up multiple times, but the apis at (Presence Api) still seem to be very inaccurate.


We will follow up on this issue.


Where do we submit the feature requests for the Open Cloud?

hi @LifeDigger - please submit a new Feature Request post on the dev forum under Website Features, e.g. Upload Images via Open Cloud API, and it’ll be brought to our attention!

1 Like

it’s not often you see DevForum updates for the web API. thanks for this!

Is there any rhyme or reason to the 9XXX status codes? Should we look at those codes or the status code when determining the cause of an error?

Not everyone has access to the features requests category so it is impossible for most of us to submit them. A survey would be a good alternative

There are numerous cases where the HTTP Status Code does not provide enough information to know the cause of an error. For example, a 403 could be returned because of a missing XSRF token, or a lack of permissions on an endpoint.

The numeric error codes are intended to uniquely identify these common base-level errors so they are easier to handle.

Will we receive a index of the error codes at some point? As in 9001 = Error 1, 9002 = Error 2, etc. Also, will they be sychronized across all APIs, or be specific to each API? Will they overlap (123 means Error 1 in the users API, while 123 means something else on the games API)?

The issue like what @NinjaFurfante07 has stated most people can’t post in this category as I believe it is for regulars only which at the current moment is impossible to get and kinda a pain ngl.

SSL Certificates are NOT required to SEND A HTTPS REQUEST.

You need one if you want a Client to be able to properly send YOUR Server a HTTPS Request.

So, the only change required is changing your endpoints’ prefixes from “http://” to “https://”.

This topic is about the * web API, and not HTTPService. HTTPService will continue supporting HTTP requests.

1 Like

This is correct.

We are requiring HTTPS for * endpoints, not for third-party domains that developers are using with HttpService.