We've allowed sign up/access to our website using Facebook Login for a long time. Two days ago, after upgrading to graph api 2.10, this stopped working for a portion of our users. Myself and most others are unaffected.
The error message received in the Access Token response reads "Cannot call API on behalf of this user".
I can't find anything in the 2.9 -> 2.10 changelog that mentions anything remotely connected to this problem, and I've found very little on this issue externally.
A few posts suggests that it might have something to do with insufficient privacy policy settings in our Facebook app settings, but everything is in place expect the non-mandatory Data Deletion Request URL. The fact that it also works perfectly fine for me as an EU citizen (affected by GDPR) says to me that it's something else. We do not have any country restrictions in place, and those who are affected by this comes from a variety of countries both inside and outside of the European Union.
Does anybody recognize this problem?
I ran into the same problem, also after an update (from 2.9 to 3.1). The fix for me was to remove location restrictions within the facebook console (Settings > Advanced > App Restriction > Contry Restricted):
I got this idea from a comment on this similar question, and this google group thread.
ref: https://developers.facebook.com/docs/audience-network/optimization/apis/FB-login-Reporting-API
sounds like the app type should be Business
today I meet this error, follow above document, I new create a business app, then error be resolved.
Related
My Adsense was working fine since last 7 years. One fine day I tried to change the bank account from Individual to Company bank account. Since then I am getting the error - "An unexpected error has occurred. Please try again later. [or-ieh-01].
I have tried-
Submitting the valid documents for the new bank account.
Reverting to the old working bank account (with the valid document for that account).
Deleting both the accounts and then try adding any of the bank account.
Neither of the above worked. Now my earned amount is stuck and I cannot use other Ad providers also as they required Google Ad Manager that is linked with a working Adsense account.
Please help me resolve this issue.
You're not the only one. Unluckily this is a known issue since mid-2021 and still unresolved. The cruel truth is, that there seemingly only exists a generic answer to this issue:
Try the path described on the official GooglePay issue fix site. Do exactly as demanded and double-check everything. In most cases that will work.
If that doesn't work contact the GooglePay Support. That's meh but you probably won't have another choice.
Or you might, as written in the official issue post, "try to use another form of payment or bank account for now".
You have my sympathy :-/
Edit: As mentioned in the comments below further ideas would be:
In case you're using it, disable VPN while you're using GooglePay as it seems to lead to conflicts.
Associate a new mail address.
Not sure, how esoteric that is, though. Those ideas came up after talking to friends and some web research.
Have you tried disabling adblocker and trying again?
I'm trying to create an ad for an unpublished page post (link type) via FB Ads API with goal set to WEBSITE_CONVERSIONS. I was a bit puzzled by api docs, so I checked hwo FB Ad Manager does this and notices it send "OBJECTIVE" parameter to FB - something that doesn't exist in API Docs at all
I have a php script in cURL that does the job, sending the following to act_xxxx/adgroups endpoint:
method=post
access_token=xxxxxxxxxxxxxxxxxxxxxxxxxx
name=CURL 001
campaign_id=xxxxxxxxxxxxxxx
targeting={"countries":["US"],"age_min":13,"broad_age":1,"page_types":["feed"]}
bid_type=ABSOLUTE_OCPM
bid_info={"ACTIONS":25}
adgroup_status=ACTIVE
creative={"type":27,"object_id":"XXXXXXXXXXXXXX","story_id":"XXXXXXXXXXX"}
objective=WEBSITE_CONVERSIONS
conversion_specs={"action.type":["offsite_conversion"],"offsite_pixel":["XXXXXXXXXXX"]}
redownload=1
When I go to FB Ad Manager and open the campaign, I can see the ad with correct objective set. Everything looks OK even if I open it with FB Ad Manager.
However, when I send the same request using the application I work on, things get messy. From FB Ad Manager campaign view, everything looks OK, but when I open the ad for editing, I get the following error for my Objective: You've entered a destination that can't be used with the Website Conversions objective. Edit Objective.
So, am I missing something, is there a point in API where this is explained?
Thank you and sorry for the long explanation.
EDIT: After inspecting the ad I created via FB Ads Manager, I noticed that creative it generated had (among other) title, image_url and link_url fields, even though creatives of type 27 shouldn't have those (according to https://developers.facebook.com/docs/reference/ads-api/adgroup/). Maybe it's something new?
After noticing the same issue arises when using the Power Manager, I reported a bug and was explained that this is by design, i.e. currently it's not an option available via API. Users who use API should define their goals implicitly by setting the correct bid info (e.g. "Clicks to website" is set by selecting bid_type=CPC or ABSOLUTE_CPM and setting appropriate bid_info.
We have an application that issue search requests (FB Graph API) using an email address as the main query parameter, so basically we are searching users by email (e.g. /search?q=email#dot.com&type=user). Everything was working perfect until yesterday when suddenly we started to get 0 results from that request. We are not aware if something has changed on the way the search API works, or if without previous notice that feature is not supported anymore. Does anybody else has had the same issue, or has any info about it?
This was a bug (https://developers.facebook.com/bugs/292220680814266) and should now be resolved. Thanks.
This functionality was deprecated because of low utilization, and they have no current plans to re-enable it. Have a look
https://developers.facebook.com/x/bugs/453298034751100/
I looked thru Facebook's documentation and they don't have specified you can search by email address, only by name. https://developers.facebook.com/docs/reference/api/ (see the searching section).
Where did you find in their documentation you can search by email address? Can you send me a link?
I'm really thinking someone hacked into that feature and now Facebook considers it a security hole, and they plugged it.
I've been storming the internet for information on how to obtain "credit_balance" from Facebook user.
To get user credit_balance, I'm using: Facebook Credits - Getting error code 13 when trying to get credit balance
I'm aware of the fact that you have to use "application access_token" instead of user's one (I've been trying both tokens lately just to be sure).
And I'm fully aware of multiple posts which are saying that getting "credit_balance" is whitelisted feature.
So my conclusion is, that our app has not been whitelisted yet, that's why I'm receiving "Exception: 13: The underlying FQL query made by this API call has encountered the following error: credit_balance is not a member of the user table." exceptions ... so it should be end of story ... but, one of the Facebook officials told me, that "credit_balance" IS NOT whitelisted feature. Now I'm confused...
My two questions:
(1)
So where the truth lies? Please, can someone confirm or refute whether "obtaining credit_balance" from Facebook is whitelisted feature and that I have to undergone the whitelisting procedure which begins with filling the form here: https://www.facebook.com/help/contact_us.php?id=157379954315015
And then wait for the eternity to get whitelisted (obviously, we've already asked to get whitelisted...). (I'm also aware of fact that after whitelisting you have to re-authenticate your users, done that as well, still no luck.)
(2)
Also is there any chance how to check whether my application is whitelisted?
Thank you in advance
Jakub
Finally, an official answer. Our application has been whitelisted for: frictionless payments, get_balance (== get_credits == credit_balance), and gamer_status.
So if anybody has problem with "getting number of facebook credits", be sure you are whitelisted first.
Facebook whitelisted us after about 1.5month, so you should apply for "whitelisting" as soon as you start your project + you should be kicking (with all respect) Facebook to reply you as soon as possible.
Jakub
I don't know the specific answer to your question, but I know that the Facebook API keeps changing rapidly, and so many of the posts/guides on the internet are outdated.
Also, a quick look on the official Facebook credit API page yields the following:
This whitelisted feature is an API call that allows an application to
determine a user's balance. It is only available to developers who
have designated Credits as their in-game currency. You can apply here.
Please Note: This feature is currently only available through the old
PHP SDK. You also must re-authenticate the user after whitelisting,
before making the function call.
Perhaps the note is relevant to you?
Today I realized that FB Connect does not return the proxied_email field in about 4 out of 5 times. (I can reproduce this with a single users repeatedly, so this obviously does not have anything to do with privacy options or permissions)
It definitely worked fine last week ago.
I could not find any official info that this field is going to be removed or anything, so...
Does anybody else have this problem? Is there anything I am doing wrong that could be causing this behavior? Or is Facebook just having a bad day?
I did the following quick fix:
$personArray = $facebook->api_client->users_getInfo( $fb_config->user_id, "last_name, first_name, birthday, hometown_location, current_location, is_app_user, proxied_email" );
$email = $personArray[0]['proxied_email'];
if(empty($email)){
echo 'Proxied email was not retreived. Trying fql query...';
$facebookFQLResultXml = $facebook->api_client->fql_query("SELECT proxied_email FROM user WHERE uid=".$fb_config->user_id);
$email = $facebookFQLResultXml['proxied_email'];
}
I'm going to posit that it's just one of those Facebook days. There is supposed to be a big change this month that will change the way developers interact with users. Notifications will be removed, etc. Facebook is going to allow full access to a user's real email address (with the user's permission), and remove the proxied email system.
However, the official word is that the email proxy system should still be supported. According to http://wiki.developers.facebook.com/index.php/Roadmap_Email, users who have already granted proxy email permissions will continue to be available. However, it doesn't say anything about new users, so perhaps they have removed the email addresses for those that did not grant permission?
I noticed that they put the new privacy controls in place today, so it could be they made a change to the proxy at this time.
The same thing happened to me too. In the Facebook Connect JS API the proxied_email works about 80% of the time, but in the Facebook Developer Toolkit (for .NET) it barely works at all (which is strange cause I think they use the same facebook api under the hood).
This probably could have something to do with the somewhat failed privacy settings introduced the other day, as the whole proxy email functionality is related to facebook privacy (as zombat mentions above)? According to http://developers.facebook.com/live_status.php, the API seems to be under a fair amount of stress at the moment, cause it's acting a bit sluggish.
Do these things happen often? Where the facebook team either decide to just change the implementation overnight or where the service more or less nosedives?
It seems that the data returned by users_getInfo doesn't longer contains the proxied_email value
You can't circumvent the problem with FQL:
$aResult = $facebook->api_client->fql_query("SELECT proxied_email FROM user WHERE uid=$fbUid");
$sFbMail = $aResult[0]['proxied_email'];
I'm using the Facebook .NET Developer Toolkit and think it's just a bit buggy, which is why it didn't always work. In the end I also worked around the problem using FQL which worked really well (with a touch of XPath)