I'm working on a custom solution to get owned page posts and comments for a client, for analytics. Client manages some 25+ pages which are all but one localised versions plus a global page, in English, which is the default to FB users not included in any of the other locales are directed to.
Now, everything (mostly /<page_id>/feed and /<post_id>/comments requests) is working absolutely fine except for the global page.
When trying to access that via the /feed endpoint all I get is sort of a timeout (response time is about 20s) and the "please reduce the amount of data you're asking for" error, regardless of the limit value set on the request or the number of fields requested. Even a limit=1 and no fields gets answered in the same way. This happens both on programmatic calls and in the Graph API explorer.
Any idea why I'm getting this on that particular page, and is there any solution (also: how is this any different from any other page)?
Related
I have a WordPress webpage with posts retrieving from a public Facebook page. The FB page is not mine. However the problem is that I have millions of visitors on my Web page and every time a user visits the web page it make an API call to FB Page. Since facebook allows only a limited number of API calls in a time frame, My limit reaches instantly with such a huge number of visitors. Is there any solution to this problem. an idea in my mind is:
1. retrieve posts from Facebook and store them locally and display them every time a user visits. Is it possible? If Yes where to start ?
Or can we get more API calls by paying facebook or things like that. I am ready to pay as far as my API calls can be made sufficient for my needs.
I am open to any solution and would be very thankful for any help to resolve the problem.
There are several possible solutions to this problem
Storing responses in database
You can add a middlepoint to your requests to Facebook API using your application. This would mean that you would have a database table which stores Facebook-related information, possibly along with a lifecycle time, like:
facebook_data(user_id, lifecycle_time, ...)
Whenever you would theoretically need to send a request to Facebook API, you can check the database table to see whether the user already has a record in that table and whether it is still valid. If so, give this data to the user. If not, send an API request to Facebook and store the response in this table.
Storing responses in localStorage/memory/file
You can also store Facebook-related data in the localStorage of the web browser of the memory of an app or a file, or even a local database specific for each user. This would prevent a lot of communication and server load your app is issuing on your server(s).
Queueing user requests to be sent
If the Facebook-related data is not very urgent to your users, you can queue requests to be sent and send a single request instead of a request for each user's each visit. You can do this via a cron job.
Periodically sending requests to Facebook
You can group your users into batches and periodically update their values via Facebook and storing in your database.
Combination
Naturally, you can combine the approaches, for instance, you can store in local memory, file, or localStorage values and in the database in the same time, so first locally stored information is searched for, not needing even a request if it exists and is still valid. If not, then checking the database record and using that if it exists and is still valid. And if the data is not found in local resources, nor your database, then you can send an API request.
I am using the graph api to get data about pages and the posts in the pages.
When a post is published, it gets liked, commented upon and shared over time. When I read the data next time how can I get the posts that have those changes alone?
the best way is really to set up a server to receive real time updates. Any other way would mean polling facebook endpoints. At a certain point, a single user access token would be rate limited, and would block you from making a call for a certain amount of time. Also, there would be more work to compare each post to the one you stored to see if anything has changed.
Really the most efficient way is to use real time updates in which you set up an endpoint on your server to receive messages from facebook whenever something on a page (or user) has changed. If cost of keeping a server running is your roadblock, I would recommend to setup a free Parse.com account in which you can set up a server to handle Facebook's incoming requests and act on that.
I hope that makes sense! More information on realtime updates here: https://developers.facebook.com/docs/graph-api/real-time-updates/v2.2
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
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:
Use the limit parameter and reduce the amount of responses you expect from the API
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
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/
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.)
A question than has been floating around is how to get the list of IDs of people that like a page (here, or here, for instance). From previous answers (and reading the FB API docs...) I am convinced that to be impossible.
However, that is not what I'm after. I don't need the user_ids at all. I just need the number of likes of a page, per city (or some subdivision of a country). There is a field for a Page for the total number of likes, which obviously isn't enough. Insights should provide this, but while page_fans_country works ok as the info is public, page_fans_city returns no results, so I'd need a different way of getting the information.
Is there a query (or set of queries) that would work? Either Graph API or FQL would be fine, at this point.
As to your first statement, I have found that to be correct aswell. My current solution includes, as it has to, external storage.
On to your actual question, it is possible via the Insights API you've found yourself. Rather than moving on from page_fans_city (because it returns no results), you should find the issue. Most likely, you're using a User Access Token without the scope manage_pages, which prevents it from becoming a Page Access token. You should also include read_insights. Read more here. For further information about the object/insights go here.
Hope this helped.
Let me explain the whole thing here so you can have a clear picture of the situation:
I have a page on facebook and the insights (both on the page and from the graph api) give me a lot of valuable information, but I need to go deeper. I was thinking of applying the social network analysis concepts (centrality, betweenness, eigenvector, etc) on who likes/shares/comments on my pages posts/pics/etc, so I can find the key-users of my page and how virality spreads among them.
Lets take 'liking a post' as an example. First thing I need is to get a list of everyone who liked that post, which is simple and can be done with a few requests to the graphapi. Now comes the tricky part: I need to know the relationship between all these people who liked the post, but I don't have access to their friendlist. To have access to the friend list I'd have to make the page an app and request that permission, which can't be done at this point. But facebook api allows you to check if two individuals (user1 and user2) are friends with a request like this: user1/friends/user2, and for that I don't need special permissions, just a regular token. Well, so far so good, I just get the users who liked the post and check two-by-two which ones are friends. But here comes the problem:
I can make batch requests to the API, which means I can check 50 pairs of users with one request. And from what I read, facebook allows 600 requests each 600 seconds. Simple math: 30,000 pairs of users each 10 minutes. It's a big number, should be enough. It isn't. Let's assume that the post has 1,000 likes (not being optimistic at all). I'd have to check user1 against the other 999 users. Now user2 would have to be checked against the remaining 998 users (no need to check against user1 again, because the friend-check works both ways). User3 against 997 users and so on, until user999 needs to be checked against 1 user. Therefore I'd need to perform 999+998+997+996+...+3+2+1 checks, or 499,500 requests, which means almost 3 hours to get the data obeying facebook limitations. 10k likes would take over a week!
So my question is: is there any other way to make this work? Another way of getting data, or a largest batch request? Some way I can retrieve this data? Or it's just impossible, since facebook retains the important information?
Thank you for reading all this and helping me out ;)
What you are trying to get to is information that Facebook does not want easily available.
In the same way that you don't have access to "friends of friends", trying to reconstruct social connections takes far too many calls to the API since, as you stated, you would need to test against individual pairs.
Whilst your question is valid and from what I can tell you are not trying to obtain this data to to perform some malicious actions, I'm afraid that at this point you'll just have to use the data that Facebook makes available to you through the Insights application and the access to that data though the API as well.