FYI, independent of the docs outage, this is bad practice and likely would likely be impacted by the Account Session Protection flags if the request also passes the cookie.
CSRF headers are visible on every endpoint that requires them, use retry logic and hold on to the CSRF token in the HTTP 403 response til the next failure.
Some day, I really should update noblox.js to do this properly, since I feel like our archaic carryover implementation of getGeneralToken has led to this widespread (bad) practice.
We used this route as we could not find a feasible fix during development for it’s use. If we do ever redo this system however, I will keep this in mind.
Can confirm adding a double forward slash is a workaround for now. https://groups.roblox.com//docs/index.html works https://groups.roblox.com/docs/index.html 404
The new pages list all API documentation that was previously available via direct docs URLs on the respective API sites, to the best of our knowledge. Please let us know if anything is missing that was available before.
You can find all these APIs in the left navigation. It also calls out on the overview page certain APIs that you can hit with legacy OAuth 2.0 / API key scopes instead of with a cookie.
Please rely on this new documentation page instead of the old documentation URLs since we cannot offer guarantees that the old URLs will stay available, including any variation (like the double slash workaround), for involved technical reasons.
While we do our best to alert you of breaking changes, please note that these legacy APIs may change without notice and break your application and do not have the stability guarantees of the newer Open Cloud APIs.
We especially discourage using the endpoints that only take cookie authentication as much as feasible for your use case, as cookies do not offer fine-grained authorization via scopes.
We are looking into improvements to the new documentation pages, like having a way to download the openAPI JSON for each surface, and we are investigating what it would take to support “try out”-esque features on this page.
You can let us know here or by filing a new bug report or feature request if you have any feedback, questions or concerns. We’ll do our best to take that into account for any changes we plan to the documentation.
Although the new pages look great, I sometimes use the v0 APIs as it includes info that you often have to get on lots of other APIs, are there any plans to remove them?
Confirmed in private messages that for maintenance reasons, we are not going to document the V0 endpoints on the Legacy APIs page and highly recommend not to use these endpoints going forward anymore. The swagger docs for the V0 endpoints have not been exposed for several years.
This is not always feasible for a couple of reasons right now. Is an eventual goal of Roblox to support all use cases for cookie authenticated endpoints via OpenCloud, or are some endpoints going to stay cookie-only (and presumably eventually get deprecated)?
The reason for the statement you quote is that we cannot officially encourage using endpoints with cookie authentication for new use cases, especially for the cases where there are also Open Cloud alternatives already which can be used today, which I hope you can appreciate. It’s not feasible for us to provide stability guarantees on these endpoints, and cookie authentication is not scoped properly in terms of permissions.
We fully understand that you all have certain tooling live right now that use these endpoints for valid reasons and it’s not our intent to break that, and we want to make sure that we properly support you with Open Cloud support. The current change only affects how/where we store swagger documentation for legacy APIs. Nothing else about our stance has changed.
ok, i might sound a bit uneducated on the topic for asking this but im a environmental designer after all, tho i will shoot my shot.
Ive been searching for documents about all the endpoints but i cant really seem to find a reliable list of all of them.
Even when i search up the swagger, not everything is always listed.
We have never exposed docs for specifically apis.roblox.com, this change only covers migration of documentation for API sites ([product name].roblox.com/docs, where product name is not “apis”).
I recommend creating a new topic if legacy endpoint documentation for apis.roblox.com is important to you and what kind of use cases are not possible without having the endpoints that that domain serves (and assuming there are no Open Cloud replacements for those endpoints yet).
Hey there, where are you getting the idea that we are phasing out APIs?
Again, as this reply states, the only change here is where the swagger / open API docs live for legacy APIs. There are no other changes other than where the documentation lives for these APIs.
We are not decreasing (or increasing) the guarantees we provide for these legacy APIs. We have never given any stability or documentation guarantees for legacy APIs. There is no change in status quo.
We are not removing any documentation. The legacy API documentation content has been migrated 1:1 to the best of our knowledge to the new Creator Hub documentation resource. (just for emphasis, again, please do make sure to check the left navigation, not just the linked page)
If anything is missing that was there before (~2 weeks ago), please let us know what is missing.
Hi, thanks for creating a unified documentation for Roblox web APIs! For many years I’ve been maintaining a GitHub repository listing Roblox API sites and hopefully now I can simply point developers to this new page.
Are there any plans to fix the broken /docs links on legacy API sites? I understand that this new unified page is the future but I suspect there are hundreds of now-broken links. One option could be to redirect those /docs links over to the unified documentation page for as long as the API site is still available.
Hey, we’re in a complicated in-between state at the moment for various technical/safety reasons I can’t further elaborate on here, but yes the ideal state we want to work towards is that everything is on the new docs page and that we have automatic redirects. (apologies for late reply, missed your post until now)
Please rely on this new documentation page instead of the old documentation URLs since we cannot offer guarantees that the old URLs will stay available, including any variation (like the double slash workaround), for involved technical reasons.
While we do our best to 
We are looking into improvements to the new documentation pages, like having a way to download the openAPI JSON for each surface, and we are investigating what it would take to support “try out”-esque features on this page.