Max. num of requests for Facebook per X interval

Aug 24, 2008 at 4:59 PM
Can Facebook be requested only 14 times in a given interval? (1 minute?)

Are there any statistics for how many calls to Facebook I can make?

For instance, checking to see if a user has an album is 1 request:
"_albums =;"

Getting photos from a user is another request:
" _photos =, _albums[j].aid, null);"

I found that above 14 calls the application quits (after numerous logs and checks this has to do with the max num. of requests I can make to Facebook).

Has anyone else had problems with this?
Aug 25, 2008 at 10:43 AM
This page discusses Facebook "Request Limits and User Sessions"-

It rather unhelpfully states "Since use of desktop applications (and hence your API key) are under the control of the users who have downloaded them, requests from a user of your application are limited at a smaller scale. Make sure that a user of your application wouldn't make more than 15 requests in quick succession. If the application gets near (or over) that threshold, it should wait a few minutes before making any more calls."

Exactly what "quick succession" means and how many minutes are a "few" is anyone's guess!
Aug 25, 2008 at 11:29 AM
Hi mthornal,
Thanks for the link - an interesting read.

Regarding "is anyone's guess" - this is simply a matter of trial and error.

I will post my findings as soon as I have them.

I will try to wait a minimum of 20 seconds and then raise that by 10 seconds until I find the right wait-interval (could be 5 minutes for all I know), but hopefully, 1 minute is still bearable for what I'm trying to do.

It also mentions in the FAQ that you can e-mail Facebook and ask them to increase your max-request calls.

On average, for my application, I need around ~240 calls (in one session). Which is 17x14 calls.
Hopefully if it's a 1 minute pause between session initiating it would take 17 minutes on each run (more if you count the time it takes to make the requests themselves).

Another solution I am thinking of, is bypassing the "quick succession" term.  Maybe instead of making 14 successive calls, I can wait 5 seconds between each call.
But that way, 240 calls would take 20 minutes (more than waiting 1 minute between every 14 calls).  I am no mathematician, but I'm sure there's a good algorithm for this somewhere :)
Aug 25, 2008 at 12:11 PM
Yeah, I'd be interested in your findings.  The trouble is it wouldn't surprise if Facebook suddenly, without notice changed this limit which might mean you start seeing problems with the number of API calls you're making again.  For my desktop app I've taken the approach of trying to get as much data as I can from big select queries using FQL rather than individual calls to specific API calls.  This introduces its own problems but these aren't in my view as bad as having to wait between the succesive calls.
Aug 25, 2008 at 12:14 PM
Edited Aug 25, 2008 at 12:18 PM
Shouldn't be too much trouble if they change it.  I have a constant MAX_NUM_OF_CALLS = 14, and I count the number of requests I make.
When I get to MAX_NUM_OF_CALLS I do Thread.Sleep(X) (where X would be the magic number), reset the request counter and continue from where I left off.

And unless I'm mistaken, FQL calls won't help me because they can only give you the details that are available to you through the APIs. 

What I managed to do is run over the HTML code generated by "View Friends" of ANY user, and then with one click of the button I can generate a "Friends List UIDs" of any user (something Facebook doesn't allow through the APIs).  Not only that, but I am filtering the HTML code to only give me the "open profiles" (public) of that user's friends (it looks for a <A HREF=... tag in the code) so all of that doesn't even use 1 request as I'm parsing HTML.

If I had a lot of free time, I would wrap that nice and tidy and add it as a class to the FB Dev Kit.
Similar solutions can be made for other queries, though I am focusing on the above at the moment.
Aug 25, 2008 at 5:45 PM
I've updated the API to account for this. You can get it here or wait for the next release.  If we get a "Too many requests" error, we sleep for 1 minute and retry the call. 
Aug 25, 2008 at 5:58 PM
Cheers mate!

Thanks for the good work!

How would this work in code though?

if i have a for loop:

for (int i = 0; ... ; i++)
   "request call to FB" (can be get photos, get albums etc) // <---- Let's say this hangs and waits for a minute



What happens when it waits for a minute?
Does the for loop continue to the next line? it does Thread.Sleep ?

Just curious...
Aug 25, 2008 at 6:46 PM
Yes, we do a Thread.Sleep(60000).  The execution will continue to the next line, but only after waiting a minute. .  Your UI thread will be blocked for one minute in that situation.  If you anticipate running into this issue on a regular basis, you might want to offload that work to another thread by using the backgroundworker class which makes running processes on separate threads very easy.  You can then call back to update your UI from the background thread.

Aug 25, 2008 at 6:58 PM
Thanks, that's what I'm doing - using a BackgroundWorker class.

I'll try out your update see how it goes.
Aug 27, 2008 at 11:36 PM
Hi Peter,
Just a little note on this code in API.cs:

                result = processResponse(postRequest(requestUrl, parameters));
            catch (Utility.FacebookException e)
                if (e.ErrorCode == 4 && e.Message == "Application request limit reached")
                    System.Diagnostics.Debug.WriteLine("Hit Limit. Wait for one minute and retry once.");
                    result = processResponse(postRequest(requestUrl, parameters));
                    throw e;

This is what you've updated.  However, I'm using a Windows form that calls this function from a BackgroundWorker class, and I want to run a timer with a label whenever the thread goes to sleep for a minute due to the request limit.  Currently, I can't tell when the thread is going to sleep from the form, so I removed the try/catch in the API.cs function and put the try/catch in my windows form.  I put the thread to sleep for a minute myself.

Also, hardcoding 60000 is not good, because maybe 20 seconds work? maybe 45? maybe Facebook will change this later.

Maybe it should be the responsibility of the developer to catch the exception and handle it himself rather than the Dev Kit.
Either that, or a different solution...