We've been receiving alerts for two endpoints, GET {anonymous-user-id} and GET {anonymous-user-id}/permissions, and we've been unable to track down the source. There has been no change to any of our client or server code bases that call the Facebook API. In fact, I'm not even sure that we call these endpoints with our code. We allow users to join our site through Facebook authentication and that's about it. So I guess I need some basic (or perhaps a better adjective: stupid? apologies) questions answered for my own understanding.
After a Facebook Login, we call https://graph.facebook.com/v2.2/me to get the user's information. Is this somehow the cause of dashboard/analytics as the GET endpoints we're seeing reported?
What is the significance of the {anonymous-user-id}? Every API call we make for user information includes their authorization token, which seems to be strictly non-anonymous.
The Alert messages list the error codes 412 "User has not installed the application" and 100 "Invalid parameter". Is there any way to get more information on which users are encountering this problem? A user ID, IP address, User agent string, etc. Or which parameter being passed in is invalid?
Even more strange than the sudden ramp up of errors is that they seem to be dying down on their own without any intervention on our part. The counts go like this:
Feb 6th: ~300 errors per day, steady for as far back as we could observe in the dashboard
Feb 15th: Gradual ramp up to ~15k per day, roughly following exponential growth
Feb 20th: Growth between +50% and +100% per day, reaching 250k / day
Feb 22nd: Finally peaks at 315k / day
Feb 25th: Steady fall off to ~250k / day then rapid fall off down to 2k on Mar 1st
Could this be some kind of brute force attempt on user records in our app? The total API call count graph shows a similar bulge in requests, so successful calls (subtracting the error counts) seemed to stay flat during this time. Finally, the deeper metrics for logins by platform did not budge. We have not been able to find any client or server logs that report any increase in errored calls to FB APIs.
One finer point: yes our server code is still using graph version 2.2. I am executing the upgrade now, after having been thoroughly side tracked by this investigation. Our Desktop/mWeb code was upgraded to version 2.8 last year, and our mobile clients are being upgraded now as well.
Please let me know if there is anywhere else I can turn to get more information on this.
Related
We (a local hackerspace) have a Tumblr blog and wanted to make ourselves a Facebook page. Before going live we wanted to import all our Tumblr content to Facebook so our fans on Facebook can browse it here as well. For this I have made an app that reads all the posts from our Tumblr blog and publishes them to our new Facebook page (backdating those posts as well). Here's my problem: after the app does about ~130 re-posts (~260 operations: publish + backdate) I start getting an error:
Received Facebook error response of type OAuthException: It looks like you were misusing this feature by going too fast. You’ve been blocked from using it.
Learn more about blocks in the Help Center. (code 368, subcode 1390008)
The block is gone the next day, but after a similar amount of operations it's back. After a couple of hours later, when the block is gone again, I introduced 6 second delays between operations, but that didn't help and after 19 re-posts I'm blocked again. Some facts:
I am publishing posts to a feed of (yet) unpublished page I am the (only) owner of.
The app is a standalone JAVA application and uses restfb to work with Facebook.
The line that is causing the error: facebookClient.publish("me/feed", FacebookType.class, params.toArray(new Parameter[0]));
All publish operations contain a link, mostly to respective posts on out Tumblr. Some contain message, caption or a name (depending on post type).
I need to re-post ~900 posts from Tumblr, I have done ~250 so far. When over, I will likely put in on server, scheduled, to keep syncing single new posts.
This app is not meant to be used publicly, it is rather a personal utility (but the code will be posted to GitHub, should anybody need it).
This is my first experience with Facebook API and I wasn't able to find a place where I could officially address them with this question. I could proceed by doing 100 posts/day, but I'm afraid I will eventually get banned for good, even though I don't feel like doing anything wrong.
I haven't put any more code here, as the code itself does not seem to be a problem, but rather the rate at which it is executed.
So, should I proceed with 100 posts/day and hope I won't be banned, or is there another "correct" way of dealing with this?
Thanks in advance!
I'm answering a bit late but I just had this problem too so I did some research : it seems that besides the rate limits shown in Facebook docs, there's also a much more limited and opaque rate for POST requests to limit spam.
It's not clearly set but it could depend on your relationship to the page you're writing to (admin or not), if you post to multiple pages and finally if you post too quickly.
To answer the question, it seems that it would have been okay if you had done like 1 post per minute or less.
I think you exceed the rate limiting for your user Id.
- 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. One user could make 19,000 of those calls and another
could make 1,000, so this isn't a per-user limit. It's a per-app
limit
- That hour is a sliding window, updated every few minutes
- If your app is rate limited, all calls for that app will be limited, not
just for a specific user
- The number of users your app has is the
average daily active users of your app, plus today's new logins
Check this: https://developers.facebook.com/docs/graph-api/advanced/rate-limiting
It looks like you were misusing this feature by going too fast. You’ve been blocked from using it.
Learn more about blocks in the Help Center.
If you think you're seeing this by mistake, please let us know.
We use the https://financialdatafeed.platform.intuit.com/v1/accounts/account_id_goes_here/transactions endpoint on a recurring basis to fetch transactions for all of the accounts we sync. We've been using this stably for quite awhile now, across a wide variety of accounts spanning 100s of financial institutions. This works great.
However, occasionally we get a report from a user who claims that we're not receiving transactions that they know to exist. Our investigation protocol is as follows:
To ask the user if they see the transactions when they sign into their bank's web site directly
To ask them to confirm that the credentials they used on their bank's web site are precisely the ones that they entered when setting up credit card sync on our site
We then manually inspect the response body from the above mentioned URL, to make sure that the HTTPS response indicates HTTP 200 and has a non-error response body (our app catches these errors correctly, but if debugging mysteriously missing transactions, we inspect the response body visually).
We look to see whether we're successfully syncing transactions for any other user that relies on the same FI. If we are, we become confident that both the bank and Intuit APIs are well-behaved, and that the problem is on our end somehow.
We sometimes ask users to try the same FI in Mint, guessing that if it fails in Mint, that it might be a bank or FI issue.
Investigation steps 1-2-3-4-5 tease out the root cause of at least 99% of the times when a user emails us to say that we're not successfully receiving their transactions. However, the remaining 1% are the tricky ones.
Today I'm faced with a situation where a user sees the txns on their bank website, swears that they are using the same creds when adding the card to our site, the HTTP response from the endpoint is HTTP 200 but contains zero transactions, but yet when the user tries via Mint they successfully see transactions.
However, the particular FI (OnPoint Community Credit Union) is not one where I can do investigation step 4, because we have no other users that currently rely on that FI. Is it possible for someone at Intuit to check to see whether there is evidence that users relying on OnPoint Community Credit Union are currently, successfully, retrieving transactions from that particular FI?
Any other suggestions for how to further deduce whether the zero-transaction response is due to: (a) user error, (b) bank server responding incorrectly, (c) Intuit server responding incorrectly, vs (d) our app behaving incorrectly?
Can you please submit a support ticket to Intuit with the Account_ID that is missing the transactions so that we can diagnose the issue? The first place to start when diagnosing the issue is to look at the Agg_status_code to make sure that reflects a '0'. If we are unable to login due to invalid credentials or MFA might be a cause of the missing transactions. I can help diagnose though once a ticket is submitted.
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.
Regarding this API: https://developers.google.com/admin-sdk/email-audit/#accessing_account_information
I have been using the Admin SDK to retrieve login history for users in our Google Apps for Business setup. When I request individual users at a time, the request sometimes takes a few hours to process (in which the state is PENDING). However, when those few hours pass, I still get the login history that I need.
The problem continues as I begin requesting more users. We have around 750 users, and of those 750~ requests I made, 725 gave me an error after waiting ONE WEEK for my requests to be processed. Even worse, the ones that did not error out are still pending! Here is the response I get when I check the status of a request that errored out:
{'status': 'ERROR', 'adminEmailAddress': '***#etsy.com', 'requestDate': '***', 'requestId': '***', 'userEmailAddress': '***#etsy.com'}
This has got to be the flakiest and most unreliable API I have ever been unfortunate enough to work with. Requests can take anywhere from an hour to over a week to process, with no indicator of success in the mean time. Errors can also happen for no apparent reason, and no messages or explanations as to why.
It looks like this issue has been resolved by the Google Engineers. Try to run the calls again. It shouldn't be in pending more than the "normal" expected time. I just tried earlier, and I was able to export login info for my users.
I need your expert advice on this one.
I have been asked to analyse a potential Facebook application.
This application is a parental monitoring for kids accounts. Basically it will search a kid status message for specific keywords amongst others things. And this application will alert the parents when it finds something.
Of course this application will have a valid token to access the kid's data. This is not a tool to spy on the kid.
I am using the Graph API coupled with the 'since' keyword to get the last updates. It's working fine with a single user.
My question is about scalability.
How should I get updates of a huge number of kids to monitor? (between 10,000 and 100,000 accounts)
And for each kids I have to monitor status messages, videos, images, friend, friends' status messages...
Here are some numbers:
~2.1M requests each day to get hourly updates of 10,000 kids' account.
~57.8M requests each day to get hourly updates of 10,000 kids'account plus their friends', with an average of 40 friends each.
And as I read here, it would be limited.
So what do you reckon?
ps: Maybe with real-time updates I won't have this problem or would it be worse?
Yes I would subscribe to real-time updates so as an account gets updated you get a callback and then you get the latest updates. This would avoid the overhead of constantly polling accounts for updates. You will need to get an offline_access token for this to work as well.