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.
Related
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.
I applied twice in the google forms for a developer key for soundcloud to use a widget on my website. It has been more than 3 weeks and I have still not got any reply from them. What do I do?
I'm afraid you just have to wait until they respond. I have applied 3 times now and keep getting rejected and the response is a generic answer not explaining why you were denied. For me I think it is the APP URL, yet they don't explain, it is so frustrating.
Did you try email api#soundcloud.com on my first rejection they were very friendly and replied with advice, however second time they did not.
You can also try calling help on +4930467247600 however they have not worked for me.
Lastly I read online that one person heard nothing from them for weeks and checked his SoundCloud developer page under 'YOUR APPS' and his app was there set up and with the client id and secret etc. He was just never informed that he got it. So hopefully that is the story in your case.
For me it took four weeks. I contacted them via Twitter and Email. They responded but all they said was:
"As mentioned previously, we’re currently working through applications
as quickly as possible, although there has recently been more requests
than usual lately causing delays.
You should receive confirmation soon though."
I have a simple message bot that was set up according to the Messenger Platform guide. It has been working fine for the last few months, with about half a dozen messages sent a day. I have not touched it at all, but suddenly, sending a message, ie calling https://graph.facebook.com/v2.6/me/messages?access_token=..., returns:
{"message":"(#230) Requires pages_messaging_subscriptions permission to manage the object","type":"OAuthException","code":230,"fbtrace_id":"DVs...."}
This was out of the blue. Things were working fine, I did not even log on to Facebook during this time, and I haven't even looked at my webhook callback website. But some time from Aug 17 onward, this exception was returned for every attempted message send.
Has something changed? Anyway, I could not find a subscription field by the name pages_messaging_subscriptions in the Webhooks Page Subscription page.
What do I need to get my message bot to work again?
August 15 was Updater Messenger Platform Policies.
official post in blog
Now, to send a message a day after the activity of the user is necessary to request additional permission in the application settings.
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.
With the Graph API, I publish a story by POSTing to the /me/feed connection. I get back a success or an error result from Facebook. So far so good. Once in a while, the API takes a long time and the connection times out. In that case, I don't know for sure if the request succeeded of failed (i.e. maybe the request never reached Facebook, or maybe it succeeded and the result never made it back to me). How do you handle this situation?
More details:
I publish a lot of posts to Facebook and Twitter, so the timeout situation happens often. With Twitter, the solution is easy. If the request times out the first time, I simply try again. Twitter detects duplicates, so if the post was successfully published the first time, then I'll get a "duplicate status" error on the second request and I know that I don't need to retry any more.
But Facebook doesn't detect duplicates, so if I retry the publish request, I risk having two copies of the post published to the user wall, which is not nice. On the other hand, if I don't retry, I risk having the post not published at all. Thoughts?
I get back a success or an error result from Facebook.
Hmmm. When I post to the Graph API, I get back an error or the id of the post. I never see any success message. What SDK are you using around the API?
Once in a while, the API takes a long time and the connection times
out.
Usually when things are running slowly, it's due to the channelUrl not being specified. See https://developers.facebook.com/docs/reference/javascript/
It is important for the channel file to be cached for as long as
possible. When serving this file, you must send valid Expires headers
with a long expiration period. This will ensure the channel file is
cached by the browser which is important for a smooth user experience.
Without proper caching, cross domain communication will become very
slow and users will suffer a severely degraded experience.