1

I'm trying to get some figures from Facebook telling me which posts have the most likes, comments and shares for a given Facebook page and within a given date range.

I can get these figures if I query the API to get all the individual posts and loop through them in my own code, but I'm often getting an error from the API "600 calls per 600 seconds" rate limit error from them, because I'm making a call for each post. I've tried using FB's batch graph requests but this doesn't reduce the likelyhood of getting that error.

Is there a way to do this so that I don't need to make so many calls?

MakkyNZ
  • 2,017
  • 3
  • 30
  • 46
  • To find the most popular one, individual API calling is the only way to go I think. /page/statuses will return all posts in one call however. But if you have more than 600 status updates to compare, you may need to wait those 10 minutes. – Fredrik Jun 17 '14 at 08:41

2 Answers2

3

Yes, you have to make individual API calls. Batch api requests are counted as normal requests [0]:

For example, a batch of 10 API calls will count as 10 calls and each call within the batch contributes to CPU resource limits in the same manner.

My tips:

  • make graph api call server-side and store results in a database
  • make some delays between each call
  • you can increase your request limit by making some delays between each
  • use multiple extended page access tokens [1] and pick random for each call
  • make calls without sdk - you can make simple GET request with eg. curl to https://graph.facebook.com/post_id?access_token=access_token

[0] - https://developers.facebook.com/docs/graph-api/making-multiple-requests/#limits

[1] - https://stackoverflow.com/a/17234650/1587309

Community
  • 1
  • 1
smalu
  • 441
  • 4
  • 9
  • How does using simple GET requests instead of the sdk help? Doesn't the sdk just make the same GET request itself? – MakkyNZ Jun 20 '14 at 21:22
  • Because it is generally faster, your authorization is based on plain access token instead of pair of application id and application secret and user/page access token issued by the same application. You can simply generate 5 apps, get plain extended page access token and rand access token each time to bypass API rate limits. – smalu Jun 21 '14 at 05:45
  • I doubt that what you say is correct. FB SDK is just a wrapper around the low level HTTP calls to the https://graph.facebook.com endpoint. And using Pages Access Tokens doesn't really help, because for a lot of actions you need an actual User Access Token – Tobi Jun 23 '14 at 07:11
  • If you use really plain http calls you don't have to include sdk and worry about auth. Adding a layer of abstraction will Also page access tokens will not expire until user will change password. – smalu Jun 23 '14 at 08:57
  • I doubt that the difference will be in a measurable dimension. Have a look how the PHP SDK works, and you'll see that it's just a wrapper around the low-level calls. And, concerning Page Access Tokens, getting infinite lasting Access Tokens in only possible with Graph API v1.0. This has nothing to do with using a SDK or not btw. Furthermore, as I wrote, for a lot of calls you'll need either an App or User Access Token. – Tobi Jun 23 '14 at 09:55
  • Still I don't see reason to force using SDK for one simple task. You can get 2 months access token and it is possible with Graph API v2.0, instead of your answer that is 1.0 only. – smalu Jun 23 '14 at 11:55
  • I haven't said that you have to use the SDK, I said I doubt that "it is genarally faster" to avoid it, and also that what you wrote about getting the Access Token is not fully correct. – Tobi Jun 23 '14 at 12:16
0

You can use FQL (which will be available at least until April 30th 2016) to achieve this in one call:

select post_id, comment_info.comment_count, like_info.like_count, share_info.share_count from stream where source_id={PAGE_ID}

Just replace {PAGE_ID} with the actual Page ID. You can also run this via a Page Access Token with the read_stream permission.

If you want just the Page's posts, add the following to the FQL query:

and actor_id={PAGE_ID}
Tobi
  • 30,855
  • 7
  • 52
  • 89
  • FQL will be available to April 30th, 2015 (end of Graph API v1.0) and only to applications created before April 30th, 2014 https://developers.facebook.com/docs/reference/fql/ https://developers.facebook.com/docs/apps/changelog/ – smalu Jun 23 '14 at 11:57
  • 1
    Get your facts right: The 1st link you are referencing says: `Version 2.0 of the Facebook Platform API is the last version where FQL will be available. Versions after 2.0 will not support FQL` This clearly states that FQL WILL be available in v2.0. https://developers.facebook.com/docs/apps/versions/#howlong states that `A version will no longer be usable two years after the date that the subsequent version is released. So if API version 2.0 is released on April 30th 2014 and API version 2.1 is released May 30th 2014 then v2.0 would expire on May 30th 2016, two years after the release of v2.1` – Tobi Jun 23 '14 at 12:14