There is an undocumented http request limit of 20 requests/minute which appears only to scale up to 500 req/minute after a few minutes of the game server being active. I managed to find this a few weeks ago and last week it was confirmed with an Engineer.
Similar to DataStoreService:GetRequestBudgetForRequestType(), it would be really nice if we had a function HttpService:GetRequestBudget(), so we can determine what the actual current http budget is. Currently, outgoing requests in our game depend on this limit being 500 requests/minute.
My game makes heavy use of the HTTP service, and something like this would be extremely beneficial to it. Even for things like the DataStore and Messaging Service, I’m not really sure there is an API to access this information. This would be a super nice feature and save devs from making their frameworks count requests - which by the way cannot account for future roblox updates.
I’m giving this both a bump and a thumbs up as this information should be available to the Developer. As I continue work on my new project, I’m implementing a way to minimize the amount of Http Requests I consume not only through queueing requests, but through GraphQL. Knowing precisely how many requests I have remaining would not only reduce the restrictions this implementation enforces, but ensure I stay compliant with the current budget.
Bump - this feature would be so easy to implement, yet immensely beneficial for developers. For games that heavily rely on HTTP requests through this service, having an accessible method to manage these would be invaluable. It would provide more flexibility with rate limiting player actions, and ensure less restrictive gameplay by allowing developers to conserve bandwidth for other players’ needs.
For example: let’s say I have a code redemption system that interacts with a web API using HttpService. Currently, when players redeem codes, the system imposes a flat 10-second cooldown. This is because the available request budget for HTTPService is not transparent, and these strict measures ensure we don’t surpass it. However, if we had a feature that provided this transparency, the cooldown could adjust dynamically. For instance, if 499 requests were available, no cooldown could be necessary. But, if there were only about 10 left, the cooldown could extend well beyond 10 seconds. This adaptability would allow the scalability of so many games’ systems and would be so beneficial overall.
Going to @ an engineer who might be able to look into this: @LiahnovTechenski
Hey everyone and thanks for reviving this thread @bvetterdays. I agree that this would be a useful feature. We are looking at potentially supporting this in HTTPService as well as other services like MessagingService.
I don’t have an ETA at this time but will share updates here when I can.
Hey again. Time flies - it’s already been a month since this reply. Just checking back in to see if you have any updates on this or could provide a possible ETA. No rush but would be highly appreciated.
Hey… again! It’s been around 8 months since your first post in this thread so I’m just checking back to see if there’s been any updates or if this proposed feature has slipped through the cracks. Even if no progress has been made, knowing that would be helpful as we are considering making our own implementation if this is the case, despite how annoyingly time-consuming this would be.
Since I’ve been reminded of this and just so happen to be working on something once again relating to this…
I understand Roblox has priorities, but I am quite baffled by the fact something like this has taken so long to implement. I know nothing of the Roblox source code, but even considering containerized applications ran through Nomad, surely there isn’t so much complexity involved with returning how much is left in a request budget?
