Currently, the only way to find out about changes to the Roblox Web APIs is to find a post on the devforum or find out about a breaking change at the time and then report it. My site, RTrack, and many other community run sites rely on these APIs, and only find out about changes once they’re already impacting us. Often it takes days or weeks to find out that there is an issue.
I propose a site, a discord, a mailing group, whatever, that you can subscribe to and when changes are planned to the API, these will be noted in this singular place to update us.
We have been using Recent and Upcoming Changes to Roblox Web APIs as an informal channel to post about web API changes and deprecation. Are you finding that some API changes are not being announced? Do you have any recent examples of this?
We strive to not make breaking changes in our APIs. Just to confirm, you are saying the linked API is one where a breaking change occurred?
We encourage you to file a bug report if you ever notice a breaking change or migration to a new endpoint that we didn’t properly announce that is used by any of your tooling.
no it’s not a breaking change, the OP is saying there should be a way to notify users of any API changes or new endpoints that we can use and integrate in our projects, as well as other stuff that can affect API requests to certain endpoints
We’re working towards a world where everything third-party developers need should be on Open Cloud, and for Open Cloud we have proper documentation that you can subscribe to (e.g. the git repository would be updated every time the documentation changes).
We’ll discuss internally, but it’s unlikely we can provide the same for non-Open Cloud endpoints for various operational reasons.
I see where your coming from, lots of people will abuse certain endpoints and whatnot, but maybe just updates for internal endpoints that can benefit developers & is not abusive like call history, new catalog endpoints, and more
I’m not really talking about that perspective here at all really. Endpoints outside of Open Cloud are primarily designed for first-party usage and the internal developers of those endpoints will not necessarily be thinking of or have time to properly document the endpoint for third-party usage.
I encourage you to post feature requests for product surfaces you want to see on Open Cloud with proper documentation, guarantees for life cycle, etc.
I get what you’re saying here, but I can’t really see how most users can use Open Cloud in the short term when doesn’t really provide that much of anything right now (compared to the Web APIs), to be frank. Not even being able to upload .rbxm files through the Asset API, the Asset API won’t let you add experience permissions (for audios), Videos were never added upon release, and the Groups API is completely read-only, for example.
Open Cloud is nowhere in sync with current features, which really just makes it completely unfeasible to use currently. It doesn’t appear like this will be changing soon either. I would appreciate a better short-term approach regarding that.
there’s lots of more approaches able to be made across different endpoints & no clarity of these endpoints can deter from new ideas. i mean stuff like roseal, btr roblox, and so much more were all made with finding documentation on endpoints.
and also @moo1210 point on how the open cloud api has barely any legible functionality for people to actually convert to using it
I think there’s a misunderstanding here. This thread is specifically talking about a change feed, not about access control.
What I’m trying to say is this: to achieve documentation and a “change feed”, it’s cheaper for us to onboard an API onto Open Cloud than to figure out a way to provide all those guarantees on an older API. It requires a lot of collaboration with the engineering owner internally of the APIs in either case, both of these options are similarly expensive in terms of workload.
There’s no magic reduction in work by saying “okay, let’s not put this on Open Cloud, let’s do just this change feed instead”. The work required is similar. So given two choices that are similar work, we would of course tend to the choice that is better for you folks in the long run.
If you want full documentation and life cycle management for specific older APIs, these are generally the options:
We do a one-off courtesy for the API domain mentioned, which is akin to throw-away work considering the long-term.
We onboard the product onto new Open Cloud endpoints according to our design principles.
With respect to access control (not documentation or change feed), we are looking into enabling you to use granular access mechanisms with scopes on these older endpoint surfaces. However, we cannot provide the complete documentation or life cycle guarantees for old APIs outside of avoiding breaking changes.
Strongly recommend though that you let us know via separate feature requests which API domains you’re using so we can encourage the owners of those endpoints to onboard on Open Cloud.
thats interesting, i didn’t realize each endpoint had an “owner”. i guess communication would be more difficult, maybe sub info channels for different popularly used endpoints
I’m unable to write feature requests as I’m not a Regular yet, but I’d like to throw in a vote for write APIs for groups on Open Cloud. We had to completely shut down our group wall as there’s no way to automatically rank up people based on certain criteria without running a self-bot, and self-bots became far more annoying to run with the recent IP locking of cookies. Not saying IP locking is bad, of course! Just unfortunate for our use case.
The day that write APIs for groups launch, we’ll be able to reopen that group wall. It’s frankly disappointing that they didn’t launch alongside the read APIs.
Yes there’s hundreds of endpoints there, with 100s of engineers from different teams having worked on these. On top of that our endpoints need to support millions of users all the time, so endpoint migrations are slow because of the high scale, there’s a lot to consider. It’s not trivial to coordinate changes to our endpoint surface because of these reasons. This is why Open Cloud is taking some time to materialize across endpoints, but the team is making steady progress in this area to look into what can be done for the older APIs.
To be completely clear, I am referring to documentation here. Although I can voice my concerns with access control too. I do really like to hear some of the things you brought up with that though. I wish these were more clearly communicated on roadmaps and such because for the most part, this is the first time I’m hearing about most of this.
In terms of documentation though, I’m more hoping to see that API domain given the same (OpenAPI/Swagger) documentation the existing endpoints have. I would also like to see newer API endpoints continue to get reasonable documentation, as it seems newer Web APIs have less and less detailed documentation and revert the removal/blanking of (harmless) existing endpoints (particularly half of Economy APIs with groups & items).
