Petition to Developers

We all felt the bump a couple weeks ago when the number of allowed API calls per user was halved. Around this time I started a thread HERE so we can all try to share how many API calls we're using so we can make sure our tools are balanced to allow our end users to use multiple API tools without exceeding their limit.

In this thread, Ched said:

The 100 limit was set as an absolute maximum, it wasn't the recommended amount for scripts to try and hit. Your scripts shouldn't really be making calls any more than once every 10 seconds (and that's in the most extreme case). API systems aren't intended for you to get live data to the second - it's highly unnecessary.

If things continue the way they are, I expect we'll be reducing the maximum calls to 10-25 per minute. We're surviving for now, but as more people start using it (especially when our official mobile app comes out), I expect we will have to make sacrifices.

I'd like to point out that a number of developers are still pushing 50, 60, even up to 95 calls PER MINUTE - which is absolutely ridiculous.

Fellow developers, please consider:

• You're not the only person making API scripts, please save room for the rest of us.
• Not all players understand how the API works, what it does, or the fact that there's a limit. If a player is using your script and sees "oh I can make it update 95 times a minute" they will likely choose that option simply because they think it's better. But then, they may try another API script, and see everything fall apart because they've exceeded their call limit. Plan your scripts to only offer reasonable options to the user.
• Due to latency in the API system and network traffic, you won't get data until an average of 1 second later anyway, so updating any more that 60 times a minute is unneeded.
• Further to the previous point, API systems aren't supposed to relay live data anyway. If you're wanting to animate graphs or counters, consider doing those calculations within your script and not relying on API calls.
• As more and more scripts are made and API usage continues to increase, it seems Ched may be lower the API call limit as needed. Please make sure your scripts are ready for this change.

In closing, let's all try to work together to make our scripts and programs work well with each other, be respectful of the API system, and plan ahead for if and when the API call limit is reduced.

I see the point, however, anyone who wants to use API scripts should understand the risks before doing so. It's their fault for not being careful and if they get banned, so be it - read the error codes, realize what happened, and wait a few minutes.

Second point, developers should add in their own failsafe. Add a warning if you have to, have an active counter of API calls being submitted, and include your own error reporting so if something fails the user knows why

lol.

The trouble is, end-users are not developers. Not everyone understands how things work. Most players aren't even aware there's a limit on the number of API calls per minute. As a developer you should strive to make things work for your users with minimal issue, and if you don't account for limitations outside of your control you're delivering something that's not ready to face the world, so-to-speak. None of us can control what Torn does, so if they change something - like reducing the number of available API calls, for example - your software should be on point to handle it.

As to your second point - There's no way for any of us to know how many API calls other scripts make. So it's literally impossible for any of us to do this. IBF and myself both offer logs within our scripts and programs, but we can't track other scripts and programs. There's no way of knowing how many calls in total across all scripts a user is using, so we need to be considerate not to crash everything for a user.

It's funny that you "lol" at this. If anything, I'm trying to help you, especially as you're the only person here who publicly admitted to using 95 API calls per minute.

About 2 weeks ago Torn as a whole crashed, leaving the game completely unplayable for everyone for a few hours. The source of this issue was determined to be an overload of the API system. Since that time, Torn identified and corrected an issue.

However, a number of users (who again are not developers and don't see things the way we do) simply think "oh, the API broke the game and I couldn't play, f**k the API."

You, being the only developer who is publicly allowing users to reach near the maximum number of calls, not only are adding extra stress to the system, but also causing issues for players by forcing them to exceed the max if they use other scripts.

You crashed it with your incomplete buggy code.
95 calls as a maximum that it can't reach.

Actually, it crashed due to Torn's buggy code. They fixed it, not me - because it was their issue, not mine. All I'm responsible for is making something that so many people used that it flooded the system (not due to number of requests, but due to number of users).

Over 1,000 people downloaded Torn Tools in the first couple days (though I can't really say how many actually use it, but I'd assume most) which resulted in an API usage higher than Torn was prepared for. Per Ched in his bulletin on the issue, there was an issue with the API system that came to light as a result of this and they resolved it.

And again, this isn't just about the server load, it's about playing fair with each other AND making sure our users (the players) don't experience an issue with the system. Users will assume more is better, so by allowing them to select an extraordinary update frequency many of them will. If your script ends up making 95 calls per minute, the user will then experience an API error if they try using any other script.

I said that our scripts use; not API calls total from a machine.

You said "Add a warning if you have to, have an active counter of API calls being submitted, and include your own error reporting so if something fails the user knows why" which I guess I misinterpreted that you meant a global total of sorts.

I'm not a developer so I rarely keep a hawk eye on my call count, but really this just seems like common courtesy and prudence to keep your calls to the lowest amount possible.

I have my DoctorN delay set to 4 a minute and I still think that's fairly high. :P

While more API calls could potentially allow us to grab more information, I have to agree with you. If everyone starts using 50-call apps, the site will be down in no time. And nobody wants that.

25 per min?? That is verry low ...

Yeah, am using 51 just for my spreadsheets, could have them manual reload and split the calls on to two sheets but it's nice having them refresh when the spreadsheets are opened.

25 is actually quite enough. If you look at the source code for CityWatch, you'll notice that it makes way less calls. Also, the APIs return "time until".. You can easily add a timer to your code. When it ticks, you display a notification to the user. Add some leeway to account for latency and you'll be fine.

Some of your scripts are like Dos attacks. You don't need 50 calls per minute. There's 60 seconds in a minute. Why do you need to refresh things almost every second?

I smell bad developers. Your apps must probably use quite a bit of bandwidth and CPU usage. I'd delete anything making that many calls per minute.

My programs use about 12 calls per minute, as do some others. I think this is kind of the happy place.

You can't really compare city watch to anything using g the api, as city watch has its own proprietary "api" calls.

Sorry for short response and any typos, on mobile.

The api is being used for more than just programs calling every min. I'm checking the prices of 24 items and checking crimes, education and player info, this is every other hour or so but is still way over your 25.

An allowance per hour would resolve that.

I don't know about that. If the parameters required an array instead of a single item ID, you wouldn't have to make 24 requests for 24 items I guess..

In either case, I get around it on iOS by logging in my account and making requests to:


self.manager.request(.POST, "http://www.torn.com/imarket.php", parameters: ["step":"getItems", "type":"Melee"])

and

self.manager.request(.POST, "http://www.torn.com/imarket.php", parameters: ["step":"getShopList1", "itemID":"2"]



I can't see any other way. The API is developed badly. It has ItemIDs without keys (IE: "ID: 1" data: {...} would have been a much better format), it has single parameter requests.. I don't think the developers expected anyone to make multiple item requests. Especially 25.

The only good thing about the API is that: For Selections you can put an array of selections but not for IDs.

Mine used 8 but could run on 4 if it really had to and adjust to it. yet after that big crash your "program" caused after your buggy loops due to negligence. You rushed your shit, it broke the servers. Learn from it before you code anything else.

Yes you can't compare CityWatch it was using a different system, designed for it.

Sorry for the long response, I didn't care.