As a developer, it’s currently too hard to integrate some public endpoints that Roblox has into wrappers. Some endpoints have a rate-limit of some kind and some don’t. As a library/wrapper developer, it often takes way too much time to spam the endpoint just to get an approximation. Instead, I propose that to the endpoints. where this is applied, are to be stated on the swagger docs in clear wording as to what the rate-limit is. By doing this, we [library/wrapper] developers can better equipped our libraries to abide by the rate-limits instead of disregarding due to lack of notice. I think transparency in this area would help immensely. ty
Getting the exact rates might not be too helpful. E.g. maybe the limit is 400 a day or 10 per second, so you limit your script to those exact amounts for that threshold. What happens when the user is calling those endpoints via normal means / web extensions / etc at the same time? You will hit the rate limit before the hardcoded one in your script.
Are you unable to honor 429 requests which get returned when the rate limit is hit? These generally provide a Retry-After header to let you know when you are next able to use the endpoint
Rather it be exact. It’s still meaningful to know so that we don’t hit the limit by mistake. Approximation doesn’t exactly help because I could spam any request and guess to where the ratelimit is. Takes time and isn’t very accurate.
My library handles this but, before you reach this point, you’re essentially spamming the endpoint. In addition, there’s no documented time that the rate-limit lasts for and I really don’t think that infinitely retrying until the rate-limit is lifted is a smart or efficient way to go about this because in theory it could be anywhere from 15 seconds to five minutes. No one really knows lol.
I think for any company with public endpoints it would be beneficial to document. Most companies, if not all, document their rate-limits.
The Retry-After header tells you exactly how many seconds until the next request is allowed. This could be 5 seconds or 18 hours. There is no infinite retrying, as the time limit before requests are allowed again is exactly returned.
If you have not hit a 429, then you are within the allowed rate limits and not spamming the endpoint.
FWIW it would be useful to know the numbers at a glance to judge whether or not it’s feasible to use a given endpoint for the application you want to use it for. If the rate limits are too strict it’s better to know immediately than to waste time poking to try and guesstimate the limits, or find out later they limit your application too much for it to be useful to you, and you have to throw away code.