Facebook api: (#4) Application request limit reached

Question

Since late November we are hitting the application limit on the Facebook API. We are fetching user's photos, and selected 25 friends photos → this is done when a user signatures in (we are building albums for the users).

The above action is limited, but it was not limited till end of November. We are using batch calls to get photos from albums - is there a better way to get this info without being limited?

BTW, according to Facebook we are doing 1M calls per day, but according to our count we are doing 180K calls per day.

Fetching only the user's photos without his friend's photos is not a solution for us.

Answer 1

The Facebook API limit isn't really documented, but apparently it's something like: 600 calls per 600 seconds, per token & per IP. As the site is restricted, quoting the relevant part:

After some testing and discussion with the Facebook platform team, there is no official limit I'm aware of or can find in the documentation. However, I've found 600 calls per 600 seconds, per token & per IP to be about where they stop you. I've also seen some application based rate limiting but don't have any numbers.

As a general rule, one call per second should not get rate limited. On the surface this seems very restrictive but remember you can batch certain calls and use the subscription API to get changes.

As you can access the Graph API on the client side via the Javascript SDK; I think if you travel your request for photos from the client, you won't hit any application limit as it's the user (each one with unique id) who's fetching data, not your application server (unique ID).

This may mean a huge refactor if everything you do go through a server. But it seems like the best solution if you have so many request (as it'll give a breath to your server).

Else, you can try batch request, but I guess you're already going this way if you have big traffic.

---

If nothing of this works, according to the Facebook Platform Policy you should contact them.

If you exceed, or plan to exceed, any of the following thresholds please contact us as you may be subject to additional terms: (>5M MAU) or (>100M API calls per day) or (>50M impressions per day).

Answer 2

The Facebook "Graph API Rate Limiting" docs says that an error with code #4 is an app level rate limit, which is different than user level rate limits. Although it doesn't give any exact numbers, it describes their app level rate-limit as:

This rate limiting is applied globally at the app level. Ads api calls are excluded.

• Rate limiting happens real time on sliding window for past one hour.
• Stats is collected for number of calls and queries made, cpu time spent, memory used for each app.
• There is a limit for each resource multiplied by monthly active users of a given app.
• When the app uses more than its allowed resources the error is thrown.
• Error, Code: 4, Message: Application request limit reached

The docs also give recommendations for avoiding the rate limits. For app level limits, they are:

Recommendations:

• Verify the error code (4) to confirm the throttling type.
• Do not make burst of calls, spread out the calls throughout the day.
• Do smart fetching of data (important data, non duplicated data, etc).
  • Real-time insights, make sure API calls are structured in a way that you can read insights for as many as Page posts as possible, with minimum number of requests.
  • Don't fetch users feed twice (in the case that two App users have a specific friend in common)
  • Don't fetch all user's friends feed in a row if the number of friends is more than 250. Separate the fetches over different days. As an option, fetch first the app user's news feed (me/home) in order to detect which friends are more important to the App user. Then, fetch those friends feeds first.
• Consider to limit/filter the requests by using the following parameters: "since", "until", "limit"
• For page related calls use realtime updates to subscribe to changes in data.
• Field expansion allows ton "join" multiple graph queries into a single call.
• Etags to check if the data querying has changed since the last check.
• For page management developers who does not have massive user base, have the admins of the page to accept the app to increase the number of users.

Finally, the docs give the following informational tips:

• Batching calls will not reduce the number of api calls.
• Making parallel calls will not reduce the number of api calls.