Developers need access to a consistent, reliable API, as well as Login methods

TL;DR at the bottom

Reiterating what the title states, it is now becoming increasingly difficult, if not nearly impossible for developers to successfully automate tasks on Roblox as a whole. This is due to a number of things ranging from obvious API inconsistency as well as a very hard to work with, and unreliable login system that involves using hacky methods to successfully log in to use Bots with.

There has been multiple threads addressing this issue, and it is clearly not an issue that a minority face. Over time updates to the logging in system has created issues for developers wishing to make use of the API for good - whether that’s automating a group, creating a reliable verification system for users, or simply creating our own API that makes life easier for both users and developers alike.


The Issue
(Logins)

Recently the Fun Captcha update was introduced, and seemingly atleast one of the reasons behind it was to prevent Bots from posting scams that users might fall for. This was effective for that specific reason… until yesterday. One of the major side effects this caused was that hundreds of “good” Bots were affected an weren’t usable any longer - practically hours of effort by Developers gone to waste, simply because they couldn’t log in to the site anymore.

There has been workarounds to logging in without having to solve a Captcha, however these are unreliable. Developers should not have to find hacky methods to log in and make use of libraries that allow them to create a Bot to create whatever they are planning on making. Logging in with a username and password just to be faced with a Captcha to solve is disruptive to workflow and does not allow developers to access functions of the site they wish to through a Bot.

(API Inconsistency)
A lot of the API endpoints available for users are inconsistent. As @Qxest explains in this thread:

Endpoint 1 puts usernames in a field called name and user IDs in a field called targetId .
Endpoint 2 puts usernames in a field called username and user IDs in a field called userId . (noted that it’s v1)
Endpoint 3 puts usernames in a field called Username and user IDs in a field called Id .
This is a hassle for Developers as it is important to be able to expect consistency when handling data from API endpoints. This is just one example of inconsistency in the API, which makes managing data received from them in responses a pain to manage.

(Myself other developers will be filing individual documentation requests for more API’s to correct them.)


Personally Proposed Solutions
Again, many threads have mentioned this issue and some have relieved more attention than others, however nearly all of them call for a distinct, user friendly, reliable, and secure way to log in and use Bots with.

Login API Tokens
Discord for example - allows the creation of Bot Users that you can access through login Tokens. This allows users to log in to the Bot and program it to fit their needs, a similar system could be effective, however this is only reliable because Discord has a well made, consistent, and reliable API which their users can avail to create bots. It is rate limited which prevents spamming or incorrect usage. If a Bot exceeds these limits the Token is reset, the creator is notified, rendering the current instance of the Bot useless as it is logged in with an incorrect token, forcing the Developer to generate a new one.

Allowing Developers (possibly 13+ users) to generate these tokens to log in to distinct Bot users will allow them to use a reliable method of logging in, so that they are aware that they can use the method in the future within the rate limits to automate whatever they wish to do.

OAuth
OAuth 2.0 is a service that allows sites to grant access to their users when they log in without using passwords. This basically allows the site to authorize a user to access their site/application with certain authorization for actions. The user gets to access the site with their information safe, and ensures that there is a reliable way to log into an account present.

These proposed solutions allow us as Developers to more effectively access features of the site that we wish to access and automate. This can be the group shout, the group wall, notifying a user of something through messages, funding users autonomously, etc. The current login method makes it difficult to carry out everyday tasks such as these examples effectively and in an uninterrupted manner. As a programmer it is annoying having to update my code to account for a completely different login method, it interrupts workflow, seems unnecessary, and prevents me from having more creative freedom in fear of my project being shut down simply because I can’t log in anymore without facing a Captcha.

One of the current methods of obtaining an XCSRF token is sending a request to the Sign Out API and obtaining it in the response, and then using it further. I see newer developers asking around all the time regarding how they can obtain these tokens, because there simply isn’t a good way of doing it. Developers should not have to use these inconvenient methods just so they can access the API to do what they intend.

Correcting API’s to be Consistent and Documenting them
The current API as we know it needs to be made consistent. A standard should be presented regarding how naming of fields in responses, requests, etc should be handled. All public endpoints should be updated keeping this standard in mind, so that users can effectively make use of the API rather than having to come up with hacky alternatives and patches for their code.

This will not only allow future API additions to be easier, but will also ensure the API is readily available for usage.

The Wiki was recently “rebranded” to become what we now know as the Developer Hub. This was an excellent update as it allows users to search for what they’re looking for with an organised, user friendly interface.

Similarly, I believe that documenting the current API in a similar fashion will prove beneficial as user’s will be able to look for what they need without wasting time searching for what they need in an API dump somewhere.


In general, while these solutions above have their pros and cons, they can be adapted. I think most Developers in the community would highly appreciate a solution to the problems outlined above, as they have gone unaddressed for a while now. These quality of life updates will allow us to develop more efficiently, whether that’s for a Hobby or a large scale project.

Thank you for taking the time to read this, please feel free to post any additions to my suggestions, or any comments on the matter below.

(TL;DR Create a more consistent API and better methods for users to log into “good” Bot accounts.)

5 Likes

Duplicate of Log in with ROBLOX, OAuth, SSO