10

So I'm struggling to find where this is documented (if at all), but I'm getting the following error message when requesting data from the FB GraphAPI.

"Please reduce the amount of data you're asking for, then retry your request"

The call I'm making is:

/v2.3/user1/posts?fields=object_id&limit=100

If I change it to:

/v2.3/user2/posts?fields=object_id&limit=100

It returns 100 items.

Why would it work for one user, and not the other?

Both requests are authenticated via an access token (not belonging to either user) and I get the same error whether running it from my code, or the Facebook Graph API console of developers.facebook.com

justcompile
  • 3,362
  • 1
  • 29
  • 37
  • not sure, why you get that error, but in general you should avoid using the limit parameter and use paging instead. – andyrandy Mar 30 '15 at 16:17
  • 5
    From what I understand, Facebook doesn’t apply any hard limits based on specific numbers, but rather on how much resources it takes to get the data. So depending on how often a user posts, what kind of posts, and what privacy value they used, you might get that error for one user, but not for another. (Since you’re saying you are not using an access token belonging to either user, the privacy level might be the most relevant factor here – for one user, they might have to “go through” only 100 posts to find 100 that your app is allowed to see – for another user, it might be 500 or thousands …) – CBroe Mar 30 '15 at 18:13
  • From my observations, this may also highly depend on the number of comments / likes the post has. – Tomasz Struczyński Apr 22 '15 at 15:04
  • So am I right in thinking that even if I don't request the comments or likes, if an item that would be returned has a high number of either, it'll kill the whole request? – justcompile Apr 23 '15 at 08:20
  • Thanks to @CBroe's answer, I simply tweaked our code to check for the `Please reduce the amount of data you're asking for` error message. If it is present, we retry the request. It eventually succeeds, possibly* because enough "dead time" has passed to cause Facebook's resource calculation algorithm to allow the request to go through. (*We really have no idea why we get this error message, or why retrying causes it to work, but at least in our scenario, this is a working, although admittedly hacky, solution.) – rinogo Sep 22 '15 at 20:25
  • Update: For some requests, simply retrying didn't help. Simplifying the query did. We're getting the error while accessing Insights, so the way we complied with the error message's recommendation was to use a smaller "datetime paging window". In other words, we made the gap between our `since` and until` parameters smaller, thereby resulting in an increased number of "smaller" requests. Kind of annoying, but it works. :P – rinogo Sep 22 '15 at 23:44
  • See this q&a for more info on this topic: http://stackoverflow.com/questions/36730867/facebook-graph-api-response-size-limiting-error-code-1 – Todd Price Feb 03 '17 at 16:42
  • I get this error when just trying to update an adset in Facebook's own console :-( – Simon_Weaver Jun 10 '17 at 21:57

3 Answers3

9

The response from CBroe is correct. Facebook returns this error if it finds that too many internal resources are needed to respond to your request.

Therefore you have to do what the response says: limit it.

This can be done in (afaik) 2 ways:

  1. Use the limit parameter and reduce the amount of responses you expect from the API
  2. Provide a timeframe (using since and / or until) to fetch only data (posts / videos) for a specific timeframe.

We had the same issue as you, but with retrieving videos from a page. Unfortunately using the limit parameter did not work, even when I set it to limit=1. But by using the since / until parameters we finally got results.

Therefore I suggest to implement a timeframe in order to reduce the amount of data, or alternatively, split the amount of requests you make. e.g. if you want all posts from the past 3 months and run into the mentioned error: split your requests in half using since and until. If that still does not work: keep splitting...

=> Divide and conquer ;)

Hope it helps, KR, ebbmo

ebb mo
  • 168
  • 1
  • 8
  • Got the same limitation using `limit` parameter. Using `since` and `until` parameters seems to better work. – Ben Tazulev Jun 27 '17 at 14:29
  • Yes, it doesn't seem to happen always, happens only sometimes, but when it happens it's a big page (Facebook page with many videos) and I just set the date range from 91 weeks ago to today then it worked – kangkyu May 05 '18 at 08:27
0

Recent bug filed on FB talks about the same error. They seem to accept that this could be a bug, but not much other information forthcoming.

https://developers.facebook.com/bugs/1904674066421189/

Eric Aya
  • 69,473
  • 35
  • 181
  • 253
jaju
  • 61
  • 1
  • 2
-5

There are both app-level and user-level rate limits that are enforced on Graph API calls. In your case, it could be that you've made a large number of calls in a short time with user1.

You can check out this page for more about Facebook's rate limits: https://developers.facebook.com/docs/marketing-api/api-rate-limiting (even though the URL refers to the Marketing API, the information also applies to the Graph API.)

subeeshb
  • 478
  • 4
  • 10
  • 3
    Sorry, but this error has nothing to do with API **rate** limiting, but rather the amount of **data** which were requested to return. In this case, the posts are probably too big (too many comments, likes etc) to be returned during one call. – Tomasz Struczyński Apr 22 '15 at 15:03