Is there any restriction on the number of entries that are retrieved using a single call to the Network Updates API? I found this forum comment "The per-user limit is per call, so 300 requests with however many updates they have." on the thread
http://developer.linkedin.com/forum/increase-search-api-throttle-limit
I want to confirm that indeed there is no limit. I have received as many as 106 entries in a single call.
Thanks in advance.
The maximum number of updates returned from the Network Updates API appears to be 250. Performing the following query as an example:
http://api.linkedin.com/v1/people/~/network/updates?count=500
Even if I try to specify the start parameter at, say, 250, I can't get the next 250 updates from the API:
http://api.linkedin.com/v1/people/~/network/updates?count=250&start=250
So it looks like 250 is the max, with no ability to page beyond that.
UPDATE:
Have verified that 250 is the maximum number returned, either in a single call or via the paging parameters. Looks like the documentation has been updated to reflect this.
Related
I want to do a query like this:
search?q=KEY_NAME&type=page&fields=id,name,location&limit=500&offset=0
when I do this the first time the result is about 470 results, now I put offset to 471 and repeat the query
search?q=KEY_NAME&type=page&fields=id,name,location&limit=500&offset=471
and the result is empty.
Why? The key_name is a famous word like "fan" and I don't think that there are only 471 results on fb pages!
What is the problem?
Never use a limit that high, afaik a limit of 100 should be the maximum. Everything else may be buggy. If you use this API call, you get more than 500 with paging:
/search?pretty=0&fields=idmname,location&q=fan&type=page&limit=100
Don´t use "offset", always use the "next" link in the JSON document to get the next batch of results: https://developers.facebook.com/docs/graph-api/using-graph-api/v2.4#paging
The next 100 entries would be available with the following endpoint for me:
/search?pretty=0&fields=idmname,location&q=fan&type=page&limit=100&after=OTkZD
Please refer to this following blog post in which it says
https://developers.facebook.com/blog/post/478/
gist of it.
As such, when querying the following tables and connections, use time-based paging instead of “offset” to ensure you are getting back as many results as possible with each call. For these Graph API connections, use the “since” and “until” parameters
I am currently creating an application that polls facebook for data. First request a page in this fashion...
pageID/posts?fields=id,message,created_time,type&limit=250
This returns the top 250 posts from a page. I then check if there page next is set and if it is make another request for the next 250 posts. I continue this recursively until there are no more posts.
With each post that is returned I go out and fetch the post details from the graph api as well.
My question is if I had 500 posts on a page. Would that equate to 502 requests? (500 requests for each post + 2 for parsing through page data to get posts) or am I incorrect in my understanding of a "request". I know when batching calls each query included in the batch actually counts as 1 request. The goal is to avoid the 600 calls / 600 second rate limiting. Thanks!
Every API call is...well, 1 request. So every time you use the /posts endpoint with whatever limit, it will be 1 request. For example, if you do that call you posted, it will be one request that returns 250 elements.
Batch requests are just faster, but each call in the batch counts as a request. So if you combine 10 calls in a batch, it will be 10 requests. The benefit of batch calls is really just that they are a lot faster: as fast as the slowest call in the batch.
If you want to get 500 posts with that example of yours, you would only need 2 calls. First one with 250 returned elements, second one by using the API call defined in the "next" value to get another 250. Just keep in mind that the default is usually 25 elements, and you can´t use any limit you want. There is a max limit for calls and it gets changed from time to time afaik so don´t count on getting the same result every time.
Btw, don't be to fixated on that 600calls/600seconds limit, it's just a general limit. The real limit is dynamic and depends on many factors. It's not public, of course. But if you really hit the limit, you are doing something wrong anyway.
I have a logic problem I can't seem to solve (might be possible).
Example:
I am inside 100 facebook groups
I need the 10 lastest posts of EACH group I am in.
That's pretty much it but I can't seem to find a way to do this without making a foreach loop calling the api over and over again, if I had a couple hundred more groups it would be impossible.
PS: I'm using FQL atm but am able to use graph, I've coded this in like 3 different ways but no success.
This is the farthest I could get:
SELECT actor_id,source_id FROM stream WHERE source_id IN (select gid from group_member where uid = me())
It only returns from one page, maybe there's no way to return all of this without a foreach asking for each groups 10 lastest messages.
There's no need to use FQL of batching. This can be done with a simple Graph API request IMHO:
GET /me/groups?fields=id,name,feed.fields(id,message).limit(10)
This will return 10 posts for each of your groups. In case there too much data to be returned, try setting the limit parameter for the base query as well:
GET /me/groups?fields=id,name,feed.fields(id,message).limit(10)&limit=20
Then, you'll get a next field in the result JSON. By calling the URL contained in this field, you'll get your next results. Do this until the result is empty, then you reached the end.
You can use batch calls, described here https://developers.facebook.com/docs/graph-api/making-multiple-requests/
Using batch requests, you can request upto 50 calls in one go. Note than batch request doesn't increase the rate limits, so if you make 50 requests in batch, it will be considered as 50 calls, and not one. However you will get the response in a shorter time.
If you think you're making too many calls, you should put some delay in between calls and avoid rate limiting.
I'm fetching a large amount of comments from a public page using Facebook's Graph API.
By default facebook returns 25 comments per response, and uses paging. This causes the need for multiple requests, which is uneccesery as I know ahead there will be a lot of comments.
I read about the "limit" parameter that you can pass to ask for a certain amount of items per response.
I was wondering, what is the limit of that parameter? I'm assuming I can't pass &limit=10000.
There's a different way for fetching comments:
https://graph.facebook.com/<PAGE_ID>_<POST_ID>/comments?limit=500
The maximum value for the limit parameter is 500.
yes, with limit parameter you can pass what number of certain resource you want in one call. default limit is 25.
for ex. if you want 100 comment in one call for a post having id POST_ID, you can query like this:
https://graph.facebook.com/POST_ID?fields=comments.limit(100)
I think they have changed this. For /feed? I only get 200-225 posts back but for comments I get as many as 2000 back
Old question, but this is in the current Facebook documentation in case anyone finds this question via search (emphasis mine):
Some edges may also have a maximum on the limit value for performance reasons. In all cases, the API returns the correct pagination links.
In other words, even if you specify a limit above what's allowed by the endpoint, the "pagination.previous" and "pagination.next" elements will always provide the correct URL to resume where it left off.
I would recommend you to use FQL instead.
FQL provide a more flexible approach where you can combine data types (posts, users, pages, etc..) as you please. You can also query for comments belonging to a list of stories instead of just one limiting your number of requests even more.
There are a couple of drawbacks though:
1. There is a limit on 5000 comments. Here you would use a query looking something like: "SELECT id, ...... FROM comments, ... WHERE parent_id in (1,2,3....) ORDER BY time LIMIT 0, 5000". Even though you split this up in several queries with "LIMIT 0, 1000", "LIMIT 1000, 1000", LIMIT 2000, 1000, etc.., you would never get anything over 5000 comments("LIMIT 5000, 1000" would return empty).
2. All real requests made on Facebooks server counts as one request. You can send of something that is actually a combination of requests, this will be counted as multiple requests.
3. Facebook does not like to heavy requests. You can end up with getting blocked for a shorter time periods(minutes -> hours, not days). If this happens, act on it.
I am looking to optimize my Facebook app.
Today I make a batch call with four graph API calls:
/me
/me/friends
/me/likes
/me/feed
If I change this to a single graph API call using field expansion like this:
/me?fields=id,name,username,friends,likes,feed
Will that now count as one hit against the API instead of four for rate limiting purposes?
Unfortunately, each call in the batch is counted as an api call, it's just faster to call them within a batch since it will be 1 request. See here documentation on Facebook API:
Limits
We currently limit the number of requests which can be in a batch to 50, but each call within the batch is counted separately for the purposes of calculating API call limits and resource limits. 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.
Source:
https://developers.facebook.com/docs/reference/api/batch/
Based on real-world testing, I've found that field expansion can count for multiple uses under the rate limit. For example, starting from a quiet state, a sequence of 63 field-expanded calls to a single api (graph.facebook.com/IDENTITY/posts) brought us to the 600 call rate limit.
According to the Facebook Docs,
The Field Expansion feature of the Graph API, allows you to effectively "join" multiple graph queries into a single call.
So your queries above would represent four calls in the Batch form, and one call in the Field Expanded form.
As I noted in a comment above: A batch sends multiple-but-not-necessarily-related queries to Facebook in a single request. Field expansion is like doing joins in SQL through a single query.