Report from Dashboard of Facebook Page Rate Limit is weird - facebook

I created a app which call the list Conversations each 10 seconds. If the updated_time is "new", i will access the list Messages. I often reach the Page Limit. But i do not know why the chart is showed as in the image (from 61% to 181% in 1 minute...).
Image of PageRateLimit report from Dashboard
P/S:
I know about the webhook, but because we want to release this version soon, we will make the webhook server later. We just want to handle to make it do not reach the limit. But look like there is no accurate number to calculate it :(

Related

Facebook Graph API Rate limit for development

I have a Facebook Application in development mode that shows as having 3 daily_active_users. From my understanding of the Graph API documentation, I can make 200 * daily active users = total request per hour, thus, I should be able to make 600 requests per hour
I am then making a Test User and trying to create a page via the accounts endpoint:
https://developers.facebook.com/docs/graph-api/reference/user/accounts/#Creating
This goes well for a single request. I then tried to script this, with 2 second timeouts in between each request, and tried to create 100 pages. After about 10 requests, I get the following response from the Facebook API:
{"error":{"message":"We limit how often you can post, comment or do other things in a given amount of time in order to help protect the community from spam. You can try again later. Learn More","type":"OAuthException","code":368,"error_data":{"sentry_block_data":"...","help_center_id":0},"error_subcode":1390008,"error_user_msg":"","fbtrace_id":"..."}}.
It states that my request is being rejected due to hitting some kind of limit, but what is this limit? I can't find it in the documentation anywhere. Is there a limit to the number of pages I can create with a test user per hour/day?

Google Plus API slow response times for large request due to max results of 20.

I'm trying to grab 200 Google Plus Activities posts for a dashboard I'm creating. But there is a max limit of 20 posts per request, and a next page token is given. Because I have to use the nextpagetoken from the previous response to make the next request, I'm not sure how I can make the requests in parallel. It takes about 1 second to get a response, so for 10 requests this is taking around 10 seconds, which is a very long time for a search result of a dashboard to load.
Do anybody have any suggestions?
Thanks!
The Max results per page limit for activities.search is 20 you can't increase that.
You can not run these requests in parallel as there is no way for you to calculate the next page token that is created for you by Google. Even if there was you would end up hitting the flood protection quota.
1 second to get a response isnt bad IMO for a free api that you are not paying for. You need to work with in the limits that Google has set for the API. Even if you want to go faster you can't if Google won't allow it.

facebook User request limit reached

We are getting the below issue when querying facebook graph API
(#17) User request limit reached
i know that this is a throttling error on user level rate limiting as mentioned in the below link
https://developers.facebook.com/docs/marketing-api/api-rate-limiting
But we were never facing the issue before, suddenly this issue has started coming, Did facebook changed the rate limits recently ?
does anybody have any idea ?
AS Per doc:
Your app can make 200 calls per hour per user in aggregate. As an example, if your app has 100 users, this means that your app can make 20,000 calls. This isn't a per-user limit, so one user could make 19,000 of those calls and another could make 1,000. This limit is calculated based on the number of calls made in the previous hour.
The number of users for your app is calculated as the average number of daily active users plus today's new logins
Not all API calls are subject to rate limits so the number of calls you make may not match what you see in the rate limit tool. Facebook also throttles calls based on CPU time used and total time. It is difficult to hit these limits, so it is an extremely rare occurrence. This information is exposed in the detail pane for each sample. Click on the graph in the rate limit tool on your dashboard for details.
Recommendations:
Rate limiting defines limits on how many API calls can be made within a specified time period. When a rate limit is exceeded, all API calls from an app are throttled and fail for a brief period of time. Once an app is throttled, the caller will get an error for subsequent calls with error code = 4, CodedException. It can take up to an hour for your requests to be accepted again.
To avoid rate limiting:
Spread out queries evenly between two time intervals to avoid sending traffic in spikes. Use filters to limit the data response size and avoiding calls that request overlapping data. Use the rate limiting header to dynamically balance your call volume.
You called API too many times (working too hard, huh?). This is how Facebook calculates the Limit. ref: link

Facebook API - User rate limit reached for a small number of requests per user token

I have an app for Android which checks for new notifications from Facebook every N minutes, where N is more than 5 minutes (default is 30 minutes). That app also makes some user-generated requests to Facebook's Graph API.
Recently (since the moment we added scheduled polling for new notifications), Facebook started to limit our app (with error #17 "User request limit reached" mostly, but sometimes it gives error #4 "Application request limit reached").
The Insights Dashboard gives us following statistics: 255,000 requests per day, 432 users. That gives roughly 590 requests per user per day, which is far from any mentioned limit for API I was able to find.
Facebook's information on rate limiting is really vague, here are some numbers you can usually find in different sources:
600 calls per 600 seconds per token per IP.
100M calls per day per app.
10,000 calls per user token per day.
The scheduled requests which our app does on a regular basis is a simple FQL:
SELECT sender_id,created_time,title_text FROM notification WHERE recipient_id=me() AND is_hidden = 0 AND is_unread = 1
Even with the minimal update interval of 5 minutes, it will be fired 288 times per day.
We tried to replace this request with Graph API call, but it didn't change a thing.
I know that there are other apps that have similar functionality and they seem to not have these limitations.
Does anybody know if there are any way to avoid being limited by Facebook with such reasonably low amount of calls?
Thanks!
It turned out that there was a nasty bug in the code which was really hard to reproduce, that sometimes forced the app to make API requests in a loop for 10-30 minutes in a row. Only a small percent of clients had that problem, but it was enough to bump into API limits.
It seems that FB API calculates limits based on the number of users of the app, so even with a rather limited amount of calls we had a rate limiting problem.
Another observation is that despite the fact that only a limited number of users were doing a lot of API calls, FB did limiting for all users.
Hope that information will be helpful somehow to resolve similar issues.

How to get Maximum App requests per day

Most of Zynga games use the Maximum App requests per day to show to the user how many requests he can send that day. I couldn't figure out how to get that daily number (dynamically) . Any hints on that? Since, I'm doing this in a flash app. I can't let the user send requests more than he is allowed. Ideas?
You can find out your Requests limit via the Developer Settings page:
https://developers.facebook.com/apps
Note that limits only apply to the older method of sending requests. If you use the newer Requests functionality, there is no limit to the amount of requests you can send:
https://developers.facebook.com/docs/reference/dialogs/requests/
Naturally, if you're being spammy, you'll still get reported a lot and automated systems could block you, so remember to keep to a reasonable volume of requests.