Anyone else have this problem?
I cannot sign up for an Azure account.
On the registration page, it asks for your phone number and wants to confirm it by sending a text or calling you. I only have a Google Voice number, and I always get
We were unable to verify your account
No matter if I choose text or call. There is no way around it. Any help?
EDIT: Other posts have indicated it's a problem when your country isn't listed, but that is not the case here (I'm in the U.S.). Those posts suggest calling "your local Microsoft branch" but how do I find that?
.
After reading the comments above, and calling Microsoft myself, I was told the verification process does not support Google Voice or Skype phone numbers.
The person I spoke with on the pre-sales department of Azure said he could not manually create an account for me or validate my Google Voice number, despite me sending him this question on StackOverflow showing that others had been successful in calling Microsoft as I had.
My solution was to use a friend's number and have him send me the verification code he received. However, it must be within the Azure signup's session timeout period or the code is no good.
I really hope someone at Microsoft sees this and corrects it for future customers.
I wanted to throw in a answer for Republic Wireless users who are having this problem.
I know this doesn't pertain specifically to Republic Wireless, but this is for those users, and should perhaps prove helpful, since this is the 1st result from Google on the error message.
Republic Wireless is a VoIP company, but they still use an underlying sprint phone number to handle calls/texts when you are not under WiFi, here is how to access your underlying phone number so you can get past the Windows Azure registration verification:
Open the Phone app (the standard dialer that comes with the phone).
Dial ##786#.
The number shown for Mobile Number is your Sprint number.
Hit the Back or Home button to dismiss the information screen.
https://community.republicwireless.com/people/carlh/blog/2013/11/20/moto-x-how-to-find-out-your-phones-sprint-number
I faced this exact same error. After trying different solutions, i decided to change my browser from Google Chrome to Microsoft Edge - and i was able to verify my account thereafter
Related
We are using what seems to be an old system of Azure MFA with PhoneFactor, which is separate from AD. It is a fairly straightforward system: we send our certified package with the phone number and PIN to https://pfd.phonefactor.net/pfd/pfd.pl, they call the number, user enters PIN, PIN matches, we get the result and let them in.
However, starting today, every attempt to connect has resulted in a 149 error. I cannot find ANYTHING about this system online somehow, everything goes to the new AD MFA in Azure, including phonefactor.com. Is anyone else using this legacy system and encountering, or has encountered, this issue?
Thanks,
Mike
I wrote to the address in the later email saying the SMS was being turned off (mfa-2waysms#microsoft.com) and they responded that they had sent out notification in July that it was being turned off. They turned it back on through March in order to implement a new solution.
I was using the following api to get the latest 3 posts from public accounts to show on the website:
https://api.instagram.com/v1/users/{user-id}/media/recent/?client_id={client-id}&count=3
I had created an app to get the client-id.
However from today, this API has started throwing the following exception:
{
meta: {
error_type: "OAuthAccessTokenException",
code: 400,
error_message: "The access_token provided is invalid."
}
}
Could you please let me know as how to resolve this?
Based on the date, you probably have an older app that got hit by the API migration today, like mine. In short, Instagram decided to make developing for their platform WAY more annoying by requiring all API requests to be authenticated per user, even for data that users shares publicly. So you (like me) will likely be redesigning you app entirely.
To tell, log in to instagram.com/developer and click manage clients; then hit edit next to the set of keys your're trying to use. Up near the top, it will have a section called 'Client Status' -- if yours reads 'Sandbox Mode', fun times ahead! Hopefully you interact with less than 10 users and can stay in sandbox mode, otherwise you'll have to write an essay, film a video, and basically plead to get your permissions back (probably in a few months, when some Instagram intern finally digs his way down to you in the pile of applications). If it reads something eles, you've got another problem altogether and should thank your lucky stars.
In the meantime, I guess I'll get back to sending out dozens of emails to the maintainers of our many, many affiliated Instagram accounts to explain the issue and try to get permissions, so provided we get approved by then, all our social media displays aren't broken during a huge event Saturday. Another option might be to use the OAuth-less json response available here, but that might break terms of service.
I have a solution to this. If you are using the same code I am, which appears likely. I was pulling the last two images using this.
https://api.instagram.com/v1/users/{user-id}/media/recent/?client_id={client-id}&count=3
What I did to get this working is the following.
Login to your Instragram account you are using as the application.
Go to the developer (API) area. https://www.instagram.com/developer/clients/manage/
Manage clients. Make sure your website URL is the same as your valid redirect URL.
Add new Sandbox User. Put in the account of the IG photos you want to reach.
Hit this URL: https://api.instagram.com/oauth/authorize/?client_id=CLIENTID&redirect_uri=REDIRECT_URI&response_type=token where the client ID is the same one you used in your previous app above.
You should get back and access token URL. Copy your access token.
Login as your account that you want the IG photos of. The account you added as a sandbox user and go to developer and approve the Sandbox Invites.
Change your original URL above from https://api.instagram.com/v1/users/{user-id}/media/recent/?client_id={client-id}&count=3 to https://api.instagram.com/v1/users/self/media/recent/?access_token=ACCESS_TOKEN with your access token.
This is the IG API Media endpoint documentation: https://www.instagram.com/developer/endpoints/users/
After that, it all worked for me and while you are in the sandbox, you should be able to pull the last 3 photos or at this point, figure out how to read the JSON to do so.
Has your app been approved after the June 1st Instagram platform changes?
http://developers.instagram.com/post/145262544121/instagram-platform-update-effective-june-1-2016
If you want to retrieve the user media file then try this, It's working for me
https://graph.instagram.com/me/media?fields=id,caption,media_url,media_type&access_token=ACCESS_TOKEN
For some reason the token is no more valid. Request it again.
Possible reasons why a token is no more valid:
changed password
verified the account
logged-in from a different country
I am using the node-whatsapi library
I am getting the number blocked. I am following the exact protocol as mentioned in the WIKI.
The flow that i follow is:
Create Adapter
Connect()
On Connect - Login
On Login
sendIsOnline()
requestPrivacySettings()
requestServerProperties()
requestContactsSync()
For Each Contact sendPresenceSubscription(), getStatus() and getProfilePicture()
And when i receive a message:
adapter.requestContactsSync('1234567890', 'delta', 'background');
getProfilePicture()
Save to DB
Now, what we do and why do we use WhatsApi
We enable our existing Customers to talk to their internal teams on WhatsApp. So, a customer initates a chat and a help desk team responds to them on an application.
Got the number blocked now. Unable to understand where am i going wrong.
Also, the total number of messages exchanged between the customer and the helpdesk team is around 1k a day.
What you're "doing wrong" is using a third party API which is against WhatsApp's terms of service and, if detected, will get your relevant accounts blocked. It's not a fault with WhatsAPI itself or how you are using it.
WhatsApp openly publishes the only approved/compliant way to programmatically interact with their network.
http://www.whatsapp.com/faq/en/iphone/23559013
http://www.whatsapp.com/faq/en/android/28000012
Outside of that, you are going to get blocked whenever you are detected as using an unapproved means of interacting with their network.
In your particular example you're using a Node.js port of the original WhatsAPI. As of May 2015 this is the kind of pressure they are dealing with from WhatsApp (despite many years of trying to negotiate an amicable compromise with them around things like message limits and identity verification):
It sucks but that's just how it is. You can look at some alternatives which are still actively updated and may continue working for a while, but given that WhatsApp is now owned by Facebook and considering the kind of legal resources at their disposal, you should be able to see why one might be reluctant to continue updating a rogue API.
Well, got a satisfactory answer from WhatsApi collaborator matteocontrini.
Here is the answer that i got, if somebody is intrested.
It says:
the reason of getting blocked doesn't have to be because you wrote
wrong code. It could be a filter on the kind of messages you send or a
report from someone about your number.
I need some advice on setting up merchant account in google.
When I try to set up merchant account, account signing up page shows me an error.
The error code is shown as "An error occurred {"type":"PLATFORM_ERROR", "payload":"0"}"
I've tried to resolve this issue with Google support team, but they keep sending me general information and manual..
Please give me suggestions on this issue. (I already finished developing my commercial application, but can't set the price because of this issue. )
Thanks in advance.
I had the same issue.
What I did to resolve it was to flush the browser cookies, history and cache. After that, I opened a new browser tab and logged in to my Google Wallet account (the one I set up previously to BUY apps on the play store). As I was logging in, I noticed there was some error but it quickly resolved itself - I successfully logged in and could see what I previously bought.
After that, I closed and re-opened my Google Dev Console, and tried to setup a Merchant Account again and it worked.
I experienced the same problem and I finish solved changing my address length, uou can't use more than 64 characters. see https://stackoverflow.com/a/21412790/2359141
clear cache and everything by using ctl+alt+delete
keep only one tab
Select proper product type , I selected Computer software its worked for me
Do sign out and login in wallet google
I found the solution.
You just have to let the VAT number empty during registration, fill it later.
It worked for me.
I got the payload error as well, what resolved my problem was changing my PO Box address to a physical address. Google chat support figured it out.
Not sure if this is related to this question (seems to be but I cannot comment only answer and I don't have one yet but would like to add my experience with this issue).
There are 3 foursquare apps I use on my Windows Phone. The official app, 4th & Mayor, and my own app. I've also experienced this via foursquare.com/mobile checkins.
Using the official app and my app, when I checkin to a venue, I do not show up in "Here Now" whether from phone apps or on the website or looking at the json from the API calls. When checking my "last seen at" it shows me there.
Using 4th & Mayor it's hit or miss. Sometimes I'll show up in "Here Now" (within all apps and the website) and sometimes I don't.
One thing to note, when it finally does show me in "Here Now" at a venue, if I checkin to another venue and I do NOT show up in "Here Now", "Here Now" for the old venue still shows me there, so it's not clearing that out. "Last seen at" shows me in the new venue.
I'm not checking in off the grid and I do have the "Include me in the public list of people who are currently checked in at a venue" checked. Even tried unchecking it and checking it back. I've tried with 2 different accounts and I've tried with and without shouts, with and without sharing to facebook and twitter, and the normal and quick checkin options. All with the same results.
NOTE that I'm not just relying on the apps showing me that I'm at a venue, I'm looking at the raw json returned from the API, both from my app and the API Explorer # developer.foursquare.com.
If it helps, here's the HTTP Post from my app (venue and oauth token removed):
https://api.foursquare.com/v2/checkins/add?broadcast=public,facebook&venueId=the_venue_id&oauth_token=my_token&v=20111030
I've even tried changing the version to &v=20120107 and it still doesn't work.
I've also logged out everwhere I could think of and even disconnected my facebook and twitter accounts.
It is only recently this has started, within the past couple days.
So, in summary,
When I checkin I do not show up in Here Now, either from the venues/VENUE_ID endpoint, the venues/search endpoint (I'm not counted in the here now), or the venues/VENUE_ID/herenow endpoint.
My checkin does show up via users/self and via the checkins/recent endpoint.
Apps used: foursquare for Windows Phone, 4th & Mayor, my own Windows Phone app, and foursquare.com/mobile.
You may not appear in herenow for a variety of reasons:
1) If a user checks in without a lat/lng, we consider that a record-keeping check-in and may not display the user in herenow since we have no idea if they are actually there or not
2) If the user checks in with a lat/lng that is sufficiently far away from the venue, we may not display the user in herenow.
Looking at your request, it would appear that you're not passing your current lat/lng to the API, which would likely put you in case (1).
The official app + 4th & Mayor should be passing your lat/lng as reported by your phone. The only reason I can think that herenow wouldn't update is if you're checking in to a venue you are not near to, or if your phone has a poor GPS look.
If you do start passing lat/lngs to the API servers, be sure that you are reporting the user's actual location as reported by an impartial device (like the phone's OS). Failure to do otherwise may cause your application to be disabled without notice.