honestly kind of surprised no one’s made a feature request on this yet but here it is
As many Roblox groups step towards an age of automation that involves automatically ranking users and running part of operations from third party communications platforms, such as Discord, recent changes (with well intents) have made it increasingly hard for developers, particularly web developers, to create services that allow users to interact with their group from their Roblox games. (and now that I look back on my sentence, I realize how much I’ve typed in a single sentence)
Let’s dive right into it!
Context 
Through this bug report 
and this announcement 
, Roblox users have been provided another layer of security - IPs that aren’t recognized by the system when logging in directly by cookie will be removed. Good for users? Definitely - I can 110% see how this can help reduce the amount of account hacks that occur due to the usage of cookies. Does this help web developers? Unfortunately not.
Many web developers, myself included, encourage users to submit an alternate account’s cookie (i.e., a throwaway account, a bot account, etc) so that we can log into that bot account and perform services for them (common use cases include ranking in groups, changing the group status). However, with this new security update, we are no longer able to log into the alternate accounts that users have submitted to us and are forced to find workaround.
Why not just use accounts that we (the web developers) own? Great question! I could. Been there & done that. Some cons of this solution:
- an automatic system typically costs money (through services such as 2Captcha, albeit a small amount of money for smaller operations, but can grow to become more expensive), and if not money, then a paid/volunteer team that would be willing to solve captchas day in and day out
- manual operation (which in itself is slow and encumbering as we have to switch between accounts and join each group)
- users lose a part of customization that they can get with using their own alternate accounts (for example, users can choose the account username [e.g., DunkinDonutsBot] rather than having a normalized username [e.g., NicholasYsBot1])
- accounts are capped at 100 groups. this may not seem like a number that most small scale operations will hit, but if you have a bot that is used by a lot of people (think thousands of users/servers), then it becomes highly inefficient to try and create more and more normalized bots to keep up with demand
Open Cloud 
Enter the age of Open Cloud drumroll please 
Open Cloud allows a safer alternative to using traditional cookies as it allows the web developers to use parts of a user’s account without gaining full access to the account. This solves a lot of problems, as the granular permission system allows users to keep their account safe and hidden away from developers while still allowing developers to provide users with services that can be extremely helpful to them.
However, the slow rollout of Open Cloud APIs has forced me to create this feature request, which would solve a lot of problems for web developers that work in this particular area, along with aiding groups that are looking to have another level of automation into their ecosystem.
What I’m Asking For
The one link summary is pretty much it:
https://groups.roblox.com/docs#
But, for a more itemized, non-exhaustive list of endpoints that I am looking to urgently request in Open Cloud is:
- GET /v1/groups/{groupId} (gets general group information)
- GET /v1/groups/{groupId}/audit-log (gets group audit logs)
- PATCH /v1/groups/{groupId}/status (sets group status)
- GET /v1/groups/{groupId}/membership (gets the alternate account’s information in the group, including role permissions)
- GET /v1/groups/{groupId}/roles (gets group roles)
- GET /v1/groups/{groupId}/roles/{roleSetId}/users (gets users in a role)
- GET /v1/groups/{groupId}/users (gets users in a group)
- GET /v1/users/{userId}/groups/roles (gets groups a user is in)
- PATCH /v1/groups/{groupId}/users/{userId} (updates a user’s rank)
- GET /v1/groups/{groupId}/wall/posts (gets group wall posts)
- POST /v1/groups/{groupId}/wall/posts (makes a group wall post)
- DELETE /v1/groups/{groupId}/wall/posts/{postId} (deletes a specific post on the group wall)
- DELETE /v1/groups/{groupId}/wall/users/{userId}/posts (deletes a user’s group wall posts)
Again, this is not an exhaustive list of Group APIs that I believe should be brought to Open Cloud, just a list of higher priority endpoints to look at (if anyone has any endpoints they have a use case for, please also feel free to add that to the thread).
Now that I’ve hit the end of my post, I feel like I’ve entered a story time that could have been avoided, but nonetheless please feel free to contribute suggestions or comments. Any and all will be taken 
