I understand the need for rate limiting.
However, 120 updates/hour is a bit tight of a pinch to get around.
When I get to work, I script the workload of a 7X24 manufacturing plant to parse potentially hundreds of differnt products I might have to work on that night. Each "potential" item is updated with what occurs during the other shifts.
I then use this "to-do" list to prioritize and accomplish my shift's assignments.
I've optomized my parser to dropping things down to sub-200 items, and am trying for the 120 target, but it is cumbersome.
In a "shared-resource" manufacturing environment, I don't have the luxury to background task/que the updates throughout the day. My resources are only available to me once my shift starts, and I need the "results" in the first 10 minutes of my shift.
If your servers can take it, bumping up to 200/hour would really help out.
Also, I thought the rate limiting was only to the API usage. I found that when I exceeded the rate limit, even the Toodledo website locked me out from adding tasks manually. (I know, I could be a bot trying to mass slam your website with add requests, but I'm not...really).
Most of my needs are with "adding" new tasks instead of syncronization. Maybe an API call for multiple item adds similar to your "batch" add already available in the website. (by the way, my solution may be to "bot" the batch add if I can't find a way to do it via an API or automatically reducing my "to-do"s)
If you use an AppID, I can lift the rate limiting for you. Just create a support ticket and let me know the AppID that you are using.
I am having trouble reconciling the description of the rate limiting algorithm with what I am seeing.
I have a Perl application that calls GetToken and then GetTasks. If I run it twice in succession, the second time it runs, the GetToken returns the "excessive API token requests" error. As far as I can see, I made 2 requests, not 120. How can I find out what data it is basing this allegation upon?
A token is valid for 4 hours. You should save the token and reuse it for successive syncs. Our server enforces this fairly strictly. It is for subsequent API calls like "getTasks" that have the 120/h rate limit.
You should also be aware that using an AppID will give you higher limits, and using the new API 2.0 will give you even higher rate limits. Anonymous use of API 1.0 is the most restrictive.
You cannot reply yet
U Back to topic home
R Post a reply
To participate in these forums, you must be signed in.