API Keys and OAuth 2.0 tokens now supported on select API Sites

Updates Announcements
#1

Hi Creators,

We are excited to announce that we will start supporting API Key and OAuth 2.0 authentication on many of our existing public APIs. The first two API Sites released are Badges API and Followings API.

OAuth 2.0 provides a secure way for users to grant access to application owners to view the users resources. Instead of sharing cookies, users can now grant access to specific permissions required by third party applications. Developers can also leverage API Keys to access our APIs instead of dealing with the friction and risk associated with cookies.

Related to this change, HBA tokens are also being released to prevent attackers from using compromised cookies (see Introducing Account Session Protection for more details). With these two releases, our API ecosystem becomes safer and gives users more control over their data.

We have introduced UI changes that communicate that these API Sites are being considered legacy. The SLA for these APIs is the same. They do not follow the same patterns or standards as our new Open Cloud APIs, and they may change without notice and break your application. Please use with caution.

There are changes required by developers to use these new authentication types. The API subdomain is now apis instead of the previous product name. The route was also updated to include legacy-{productName}. For example, badges.roblox.com/v1 is now apis.roblox.com/legacy-badges/v1 for API Key and OAuth requests. Our existing cookie-based APIs remain the same. This change modernizes our APIs and increases parity with the existing Open Cloud APIs.

We are actively working on adding support for experience-related APIs and others. We will update this doc as soon as they are available!

Please read our Open Cloud docs to learn more about creating API Keys and OAuth applications.

We are excited to see what you will build,

The Open Cloud Team

This post will be used to list all existing APIs that now support these new authentication types.

Badges API

Docs: apis.roblox.com/legacy-badges/docs/index.html
Url: apis.roblox.com/legacy-badges
Auth types: API Key and OAuth
Scopes: legacy-universe.badge
Endpoints:

UpdateBadge

  • PATCH v1/badges/{badgeId}
  • Operation: write

Followings API

Docs: apis.roblox.com/legacy-followings/docs/index.html
Url: apis.roblox.com/legacy-followings
Auth types: API Key and OAuth
Scopes: legacy-universe.following
Endpoints:

Follow

  • POST/v1/users/{userId}/universes/{universeId}
  • Operation: write

Unfollow

  • DELETE v1/users/{userId}/universes/{universeId}
  • Operation: write

GetFollowingStatus

  • GET v1/users/{userId}/universes/{universeId}/status
  • Operation: read

GetFollowings

  • GET v1/users/{userId}/universes
  • Operation: read

GetFollowingsV2

  • GET v2/users/{userId}/universes
  • Operation: read
77 Likes
#2

This topic was automatically opened after 10 minutes.

#3

Will API Key and OAuth 2.0 authentication support eventually be added for ALL of the existing and supported public APIs in the future?

14 Likes
#4
9 Likes
#5

Amaznigggg!!! Thank you to the Open Cloud Team for pushing out these amazing updates! :heart: :tada:

A project I work on is currently using developer products, and the API is very very unreliable and it’s “internal server error” every other night/every night → Is developer products with Open Cloud planned?

9 Likes
#6

I’m aware. I’m asking if they will be added for the rest of the existing apis in the future, or if there will be certain ones that will be excluded.

5 Likes
#7

for best security practices, likely most. an engineer told me and a few others that some sort of asset upload API would be coming to open cloud as well

8 Likes
#8

Love it! Will we see Swagger documentation on other apis.roblox.com endpoints? I really enjoy them.

Additionally, will it ever be possible for members of a group to authenticate OAuth apps with permissions in the group? I can see this working by allowing the group owner to determine which scopes can be granted by role.

This would be appreciated as currently I don’t want to manually share API keys with our team members as we scale, and I attempted to work around this with OAuth and realized you need to own the group.

Because of this limitation, I’m planning on creating basically a wrapper for this by having my own web API that uses OAuth to check if you are within our group and have the correct role, and automatically creates an API key specifically for you with the proper permissions. I really don’t like the idea of sharing a single API key for everyone on our team (and it sounds a bit fun/wild to do).

10 Likes
#9

Would be great to have all the Group API with that same feature!

12 Likes
#10

My Typescript Roblox API wrapper now supports these new(ish) endpoints.

LegacyBadgesApi docs → https://open.blox.wiki/cloud/legacyBadges/updateBadge
LegacyFollowingsApi docs → https://open.blox.wiki/cloud/legacyFollowings/universeFollowingsForUser

Install

npm i openblox

Example Usage

import "dotenv/config"

import { setConfig } from "openblox/config"
import { LegacyFollowingsApi, LegacyBadgesApi } from "openblox/cloud";

setConfig({ cloudKey: process.env.CLOUD_KEY })

;(async () => {
  
  const { data:followings } = await LegacyFollowingsApi.universeFollowingsForUser({ userId: 45348281 })
  console.log(followings)

  const { data:success } = await LegacyBadgesApi.updateBadge({ badgeId: 2124533401, description: "hello" })
  console.log(success)

})();
5 Likes
#11

Is there any reason why the read endpoints are seemingly not yet supported on the legacy parity API for badges?

Also, I noticed that the legacy APIs have much more generous rate-limits than the newer counterparts:

Legacy followings API:
image
10,000 requests, resets every 2 seconds.

New OpenCloud followings API:
image
500 requests, resets every 6 seconds.

While I doubt anyone is actually using all 10,000 requests every 2 seconds; the stricter rate-limits could cause problems for other legacy APIs which are hit more often. This adds friction for some developers who hit the endpoints quite often and makes the switch also have tradeoffs, hence making it not a “no-brainer” decision for such developers.

7 Likes
#12

No, we will not support all of them. Some are considered too high risk (for example, those that spend Robux, like CreateBadge), and others will not be supported because they do not align with company priorities or are already supported in existing Open Cloud APIs.

9 Likes
#13

Currently, there are no plans to onboard the Developer Products API due to various implementation details. However, if this issue persists, I encourage you to submit a bug report. Reliability is a priority for us, and any API that consistently fails should be investigated.

5 Likes
#14

Is there any reason why the read endpoints are seemingly not yet supported on the legacy parity API for badges?

Yes, most of them do not require authentication, so we decided we should focus on onboarding other endpoints instead.

the stricter rate-limits could cause problems for other legacy APIs

Yes, we are setting rate limits on a case by case basis and intend to set them sufficiently high for all APIs.

10 Likes
#15

Just to follow up on this, @appletree008 is talking about adding OAuth and API key support for the existing dev products API.

Full Open Cloud support for dev products is on our radar and not ruled out; can’t make any promises either though. We’d like to do it, and feedback like this is a helpful prioritization signal.

@Bulldo344 FYI

4 Likes
#16

I’m very happy to see progress regarding OAuth2 support and Open Cloud. I’m essentially just waiting to be able to write with group resources (bless that we have read now!) before I dip my toes in.

My number one use case has always been Roblox verification (allowing a Discord bot to cleanly and directly know a Roblox account for data tooling) and semi-automatic group management without the pain of cookies or “add this text to your description” type services.

image

2 Likes
#17

Love it! Will we see Swagger documentation on other apis.roblox.com endpoints? I really enjoy them.

This is TBD right now. Because we do have the existing docs (e.g. Swagger UI) we may not create the new apis.roblox.com docs for all API Sites. We will keep you updated.

Additionally, will it ever be possible for members of a group to authenticate OAuth apps with permissions in the group?

Are you asking about any scopes in particular? We may consider this in the future, but it is not on our roadmap this year.
Does the “Create group API keys” permission help solve your problem?

#18

There are some particular ones that are useful (from dev perspective), such as asset, universe, universe-places, and universe-datastores. We make use of external tooling (Rojo, Lune, etc.) within our studio, and we’ve made things that help us with this workflow and move quickly.

Unfortunately, it is tedious to manually maintain API keys at scale (multiple groups, growing # of team members, granular permissions, etc.). I had hoped OAuth would get me like 90% there, but unfortunately not.

Thankfully yes, but in a weird way - I ended up creating my own API that you sign into with OAuth, it verifies your account, and creates API keys for you with the appropriate permissions based on who you are, what groups you’re in, and your roles in them.

Otherwise, no. That permission allows them to create an API key with any permission, which isn’t what I’m looking for here.

I’ve created a feature request thread so it can be better tracked internally (or something, at least): Allow group members to grant OAuth app permissions to groups they don't own

I look forward to really anything. I hammer a lot whenever these API things come up about documentation because there’s a lot going on under apis.roblox.com that simply has no docs at all.

Hopefully we can get a consolidated docs page (similar to the old api.roblox.com/docs) again sometime soon, especially as more formerly documented APIs get deprecated/removed and migrated there. I’ll create a feature request for this too if there isn’t one already, maybe that helps move this further.

1 Like