Just to clarify, my suggestion wasn’t about allowing unlimited checks. I fully intended for there to be a limit on the number of users that can be queried within a set time period, so this wouldn’t create a way to bypass existing API call restrictions.
But let’s address the mug bots directly. If they’re allowed under the current rules, then what’s the issue with making them more efficient? If they operate within the same rate limits and cooldowns as everyone else, this wouldn’t give them an unfair advantage. It would just reduce unnecessary strain on the API.
You’re right, I am relatively new to Torn’s API, and from what I’ve read in the documentation, it clearly states that each user is limited to 100 requests per minute across all of their keys, not 100 per key.
If that’s not how it works in practice and people can just swap API keys once they hit the limit, then that seems to defeat the purpose of having a per-user cap. If key-pooling effectively bypasses the limit, that’s a separate issue.
That said, if the goal is still to stay within the 100 requests per minute limit, my suggestion wasn’t about increasing that, just making those requests more efficient. Sure, key-pooling might solve some of the problems I’ve mentioned, but it feels like a cleaner solution would be to reduce the number of individual requests needed in the first place.
As for the technical side, adding a limiter on how many users can be queried per request would mean adjusting how the API processes batch calls. It’s not about raising limits, just streamlining how data is accessed. Plenty of APIs already handle batch requests with safeguards against abuse, so it’s a matter of implementation, not an impossible change.
Ultimately, I’m just looking for ways to cut down redundant requests while keeping the same overall limits.
The API limit is 100 requests per minute, so the "1k requests per minute" scenario doesn’t apply here. I’ve already explained that my suggestion includes a limiter on how many users can be queried within a set time period, so you wouldn’t be able to pull more user data than you can now. It would just be done more efficiently.
This isn’t about increasing the amount of data someone can access. It’s about reducing redundant requests for legitimate use cases. The same limits would still apply, just with less strain on both sides.
What this would allow is the ability to query the same amount of users as you can now, but in fewer requests. That means you’d still be within the token’s limit, but you’d have API calls left over for other types of requests — like fetching faction data, checking market prices, or anything else — without burning through your entire allowance just checking user statuses.
I get the feeling we’re going in circles, so let’s agree to disagree on this. I still think there’s a way to implement this responsibly, but I respect that we see it differently.
Just to clarify, my suggestion wasn’t about allowing unlimited checks. I fully intended for there to be a limit on the number of users that can be queried within a set time period, so this wouldn’t create a way to bypass existing API call restrictions.
But let’s address the mug bots directly. If they’re allowed under the current rules, then what’s the issue with making them more efficient? If they operate within the same rate limits and cooldowns as everyone else, this wouldn’t give them an unfair advantage. It would just reduce unnecessary strain on the API.
Following that logic, you might as well remove the user endpoint entirely since that’s what allows those bots to work in the first place. The reality is, if someone is breaking the game’s rules by abusing the API, the proper response should be to log their tokens and punish them accordingly — not to block useful features for everyone else just because of a few bad actors.
The goal here is to improve efficiency for legitimate use cases — reducing unnecessary API strain and simplifying development — not to make it easier for bots. Security and abuse prevention should come from proper monitoring and enforcement, not by avoiding improvements altogether.
Shutting down ideas without considering how they could be implemented responsibly doesn’t move the discussion forward.
I understand the concern about potential abuse, but I respectfully disagree that this idea has more cons than pros. The goal here isn’t to enable mass tracking—it’s to reduce unnecessary strain on the API and simplify development for those using it.
Right now, applications that need to check multiple users are already making several individual requests, which can be inefficient for both the client and the server. Allowing multiple user IDs in a single request, with the right safeguards in place, could actually reduce overall load while making API integration smoother.
Of course, proper limits and restrictions would need to be in place to prevent abuse, but dismissing the idea outright overlooks the benefits it could bring to both efficiency and usability.
Yeah, that's a good point — I get the concern about someone trying to track the whole user base constantly. But maybe there could be a limit on how many IDs you can include per request, like 50 or 100, so it doesn’t get out of hand.
The idea isn’t to make mass tracking easier — it’s just to cut down on the number of individual calls for legit use cases, like checking a list of targets or monitoring a group of friends. Right now, people are already making those calls one by one, which probably hits the servers harder than just bundling them into one request.