API Limit per Users not by API Key

144 views
Skip to first unread message

mootoh

unread,
Jan 23, 2010, 9:31:30 AM1/23/10
to Remember The Milk API
Current API use is limited by the how many requests the "API key"
issues. It is not suitable for the application that uses the same API
key among lots of users. To avoid the API limit get reached soon, the
app has to insert a delay between API calls. It leads to users'
frustration.

Please limit the API per users, not by API key.

Omar Kilani

unread,
Jan 23, 2010, 9:29:29 PM1/23/10
to remembert...@googlegroups.com
Hey mootoh,

We don't limit requests by API key -- we (usually) limit them by user.

Your app/library doesn't really need to pause between requests, unless
you're doing a tonne of requests (in which case, you should probably be
thinking about why you're doing a tonne of requests :)

There's a certain leeway on how many requests you can burst up to per
period of time and you automatically get throttled (where throttled
means your request is artificially delayed) if you go beyond reasonable
limits.

We monitor the API closely to see how many requests actually get cut off
due to going way beyond any reasonable limit -- and these are very tiny
percentage coming from one or two keys which are a little too happy
calling tasks.getList every couple of seconds.

So, to summarise -- if your app plays well with the API, you should
never see any request limiting related issues. If you do, then you can
let us know specific details (request URLs, etc) and we can look into it
for you.

Hope this helps!

Regards,
Omar

mootoh

unread,
Jan 28, 2010, 1:00:56 PM1/28/10
to Remember The Milk API
Hello Omar,

Sounds great, I'll take care of API use and remove the annoying sleep!

Thanks,

galeksic

unread,
Mar 24, 2014, 9:37:41 AM3/24/14
to remembert...@googlegroups.com
Hi Omar!

you should probably be thinking about why you're doing a tonne of requests

I'm synchronizing Google Calendar events with RTM tasks (my RTM tasks are events in GCal, and vice versa), so I can enjoy moving them and re-sizing them with my mouse in my Google Calendar and after few or several minutes getting them updated (with events().list() -> updatedMin and rtm.tasks.getList -> last_sync) in both Google Calendar and RTM. And it works (more - less) nice.

But, the problem is when I make some change while synchronization is ongoing - so few or several times per day (when I see that happened), I simply remove all events from Google Calendar and import them from RTM. And it needs some time, depending on the number of tasks (50, 150, 250 seconds...).

Also, when I want to synchronize some change in existing task, I use four API calls (rtm.tasks.setName, rtm.tasks.setTags, rtm.tasks.setDueDate, rtm.tasks.setEstimate) because I don't know what is changed, and I'm just "merging" name, tags, due and estimate time.

And finally my questions.

[1] Can we expect batching support in RTM API, like there is in Google API?

We don't limit requests by API key -- we (usually) limit them by user.

[2] Are "pro" users limited to same 1 API request/second, or they can make more?

Because this thread was started in 2010, and now is 2014, I'll check again here in 2018 to see if there is answer from you, so take your time! Cheers :) 

Sergey Bondarenko

unread,
May 15, 2017, 9:44:43 PM5/15/17
to Remember The Milk API
Hi Omar,

As far as I can see, API calls are limited not per user, but per IP address for an API key.
I've built an app that calls tasks.getList() every two seconds (btw, I have to do that since RTM API has no polling/notifications/websocket support).
When I use it for two different accounts from two different devices, using the same external connection (my provider's Ethernet), I see average response time increase up to 1 sec/request.
When I use the same two different accounts from the same two different devices, but one of them connected via my cell phone carrier, then there is no response time increase.
While this should not be an issue for normal users, it may be an issue for corporate users.

Could you please confirm the observed behavior, and advice a way to fix it (either in my app or by RTM)?

Thanks a lot,
Sergey
Reply all
Reply to author
Forward
0 new messages