Whatsapp Cloud API can go live on production - whatsapp

I have successfully setup my account on whatsapp developer app by meta and can send messages to 5 free users. Now the question is how can I go live with the app. I have no verified business manager account, is that necessary?
What will I need to do after verification of business account? Do I need to generate permanent access token and it would work fine?
Plus I need to know how can I send messages to groups on whatsapp?

Yes, you need to become a verified business account and all would work as you saw with the demo account, with no restriction on the number of destinations.
First 1000 conversations/month it's free, you can check details here: https://developers.facebook.com/docs/whatsapp/pricing/
Bear in mind, you will NOT be able to message groups with the WA Cloud API. If you need to, you will need to rely on custom APIs that do that. There are some available, see the one shown here:
https://youtu.be/lCmoay0G86M

Related

Is it possible to identify the person talking to the google assistant by voice?

Recently google has added multiple user support to the assistant so how would use the API to identify the person by voice?
It depends what you mean by "identify the person".
There is no way for an Action to get the raw audio, so there is no way for it to do voice printing or anything along those lines.
Although each voice has to be reported against a Google User ID, you do not have direct access to that user ID.
What developers do have access to is a UID that is sent along with each request to your fulfillment server. This UID is consistent across requests, although it can be reset by a user (for example, if they reset their Google Home). You can think of this the same way you think of an HTTP cookie - you can track the UID and, if you see it again, have reasonable assurance it is the same user that accessed it last time. This breaks down, however, for the "default" account on Google Home, since anybody who doesn't have an account will map to this user.
Beyond this, you can also use Account Linking to connect a Google Account consistently to an account in your own system. If you have sufficient authentication in place, or are using one from Google or Facebook for example, this can act as an identity.
There isn't an API for developers to identify users by voice.

Instagram API app after june 1 2016

The Instagram new API policy have become super strict. They are not allowing fetching public content at all. We are literally following all Instagram policies and still cant get approval of public_content.
Is there any workaround or any possibility of fetching the data.
This is the response that I have recieved from instagram
General issues:
Policy Violation (Ad network, Influencer network, Other related): Your
app should not attempt to build an ad network on Instagram, nor
transfer any data that you receive from us (including anonymous,
aggregate, or derived data) to any ad network, data broker, influencer
network, or other advertising or monetization-related service. In
working to build a high quality platform, we ask that you comply with
our Platform Policy
(http://wwww.instagram.com/about/legal/terms/api/).
Yeah, they now grant permissions only to applications with some specific usage cases.
According to Instagram official website, these are:
To help individuals share their own content with 3rd party apps
To help brands and advertisers understand and manage their audience and digital media rights
To help broadcasters and publishers discover content, get digital rights to media, and share media with proper attribution
Note that in order to get public_content permission, you need to fall under the 2nd or the 3rd use case. Otherwise, consider changing your application / service in such way that is now uses basic permission and acquires only your users' media.
There is no valid and legal possibility to fetch public data except for successful passing the Instagram permission review.
This official developer documentation page may be useful to you.
You need to enable scopes invividually for your client https://api.instagram.com/oauth/authorize?client_id=CLIENT_ID&redirect_uri=APPC‌​ALLBACK&access_token=ACCESSTOKEN&response_type=code&scope=public_content in your browser, using your values for the uppercase words? This should enable your registered client to work with the public_content scope.
https://api.instagram.com/oauth/authorize?client_id=xxxxx&redirect_uri=xxxxx&access_token=xxxxx&response_type=code&scope=public_content
your comment
Read the error message, did you supply a valid client-id from your instagram developer account. Did you setup a redirect_uri for that client? Do you authenticate to instagram to get an access token?
This worked for me this weekend. Double check the values you set in the url and call it directly in your browser.

Another account access my Analytics API

I want to build a dashboard to my clients access your respective website analytics. But, after some research, I'm stuck.
Let's imagine the scenario:
My Analytics Account:
Client X - websitex.com
Client Y - websitey.com
In my dashboard, when the cliente Y log in, the data (pageviews) of websitey.com is shown on graphics.
But, there's a way to do that? By the moment, the only thing i got is retrieve information for my logged account (my analytics ID), not the information about another account.
There's a way to use the Google API, or, I'll have a "separate database" to save data each website?
Sorry, I'm really lost at the moment.
You can only view Google Analytics Accounts that you are authorized to view. For some reason this is a source of major confusion (seeing that your are not the first to ask), although it should be fairly self-evident.
If you want to see data from your clients account you have to ask your client to add your Google email to the GA account. If an email address is added to multiple accounts you can, via the API, choose between the accounts. Clientside authorization (OAuth2) will only work as long as somebody is logged in via a client application (usually a browser). The practial effect is that everybody who is authenticated via OAuth against Google will see only his own GA accounts, not other peoples data.
If you want a serverside application to pull data from various GA accounts you need a service account. But even the service account needs to be added to the GA accounts.
You can use the core reporting API, but the API will not give you access to accounts that you are not authorized to look at; your client needs to authorize you (or your applications service account).

Can the Yodlee API be used to retrieve the transactions on any credit card?

A client I work with wants to know if it's possible to use the Yodlee API to look up recent transactions on any credit card.
They'd like it to work without the user needing to be signed up with Yodlee, either directly at the site, or indirectly through a branded partner.
I assume this would be possible if the credit card company itself shared it's transaction data with Yodlee directly, and made it available to their API customers, but I haven't been able to figure this out from the docs available on their website, and haven't been able to reach anyone at Yodlee themselves to ask.
I work for Yodlee. Sorry to hear you're having a hard time getting a hold of us. To answer your question, yes the user has to explicitly authorize any application that leverages the Yodlee API and explicitly add access to their financial accounts for that application.
Best,
Grace
Yodlee screenscrapes websites to retrieve it's information.
Which means that they physically (but in an automated fashion) visit the website in a browser (IE8). Thus to pull any information down they have to visit the website, log in successfully, (optionally but more so on more banks; authenticate the computer) and then they can see all of the information that the user sees. Their API acts as a real time bridge between you (the end user using your website or app) and this browser.
So you have to either implement their very much so convoluted Yodlee API or use one of their generic hosted pages and direct the user to it where upon he/she enters the necessary information. You also have to have an agreement with them too. You also have to convince the user to do it :)

Account Strategies on New Social Enabled Sites

So I'm in the midst of creating a Facebook Connect enabled site. The site in question will leverage your social graph - as defined by your facebook account - to do social things (what is really not important here). Here's the big question I have:
Are people still rolling their own authentication heuristic when using something like Facebook Connect? That is, are newer (FBConnect) sites today providing only FBConnect as an authentication strategy, or are they pairing it with other auth strategies (such as Google Auth, Open ID, etc)? What do you think is the best way to go? With Facebook having over 300,000,000 users now, is having 1 authentication strategy (FBConnect) enough? Or is it proper netiquette to provide users other means?
Some of the references I have been looking at today:
http://www.kenburbary.com/2009/08/five-reasons-companies-should-be-integrating-social-media-with-facebook-connect/
Increased Registration - Data from Facebook states that sites that use Facebook Conect as an alternate to account registration have seen a 30-300% increase in registration on their sites.
• Citysearch.com – Daily site registrations have tripled in the 4 months since Facebook Connect testing began
• Huffingtonpost.com – Since integrating with Facebook Connect, more than 33% of their new commentor registrations come through Facebook
• Cbsinsider.com – Over 85% of all new user registrations are coming from Facebook Connect
http://www.simtechnologies.net/facebook-connect-integration.php
"according to the current statistics using facebook connect increases 30-40% user traffic as compared to non-facebook connect websites."
http://wiki.developers.facebook.com/index.php/Connect/Authentication_and_Authorization
Our research has shown that sites that implement Facebook Connect see user registration rates increase by 30 - 200%.
No Need to Create Separate Accounts
In general, it's not a good practice to force a new user to create a separate account when registering on your site with Facebook Connect. You'll have the user's Facebook account information, and can create a unique identifier on your system for that user.
Just make sure you understand what Facebook user data you can store, or simply cache for 24 hours. See Storable Information for details.
If the user ever deactivates his or her Facebook account, you have a chance to contact the user to request the user create a new account on your site. When a user deactivates his or her account, we ping your account reclamation URL to notify you of the deactivation. Then Facebook sends the user an email regarding the deactivation. If the user has connected accounts with any Facebook Connect sites, and if your site has specified an account reclamation URL, the email will contain a section with your application logo, name, and reclamation link, in addition to an explanation about the link's purpose. For more information, see Reclaiming Accounts.
http://www.chrisbrogan.com/how-facebook-connect-points-the-way-towards-velvet-rope-networks/
The Drawbacks
Though there are advantages to using Facebook Connect for integration, there are some drawbacks, mostly from the marketer’s point of view. If you build out a social network project using Facebook Connect, Facebook gets all the information and you get none. You don’t get a database of users. You don’t get a way to message people participating in your event, except for “in stream,” the way everyone else is using the app. You don’t have any sense of demographics, nor any control abilities to block trolls or other unwanted types.
Crystal Beasley "All of the FB Connect sites we have built so far have incorporated "standard" accounts as well, even with the added complexity of supporting dual login methods."
There are still people who use mySpace (myself not included), and I know a several people coming out of college that have completely deleted their FB accounts to get rid of information of them they don't want potential employers to find (I know, there are a lot easier ways of doing this). If there are people who for whatever reason do not want to have a FB account, at least give them the option of creating a private google account.
Using ONLY Facebook as the register/login-method seems pretty dangerous to me. If you had a regular user management system, with Facebook Connect to speed up the process from a user-perspective is a good idea.
The Problem is somewhere else
if you really want to leverage the social graph only facebook brings "pure" data
the graphs people build at e.g. myspace arent telling much about that person and its social env. - at google neither
if you are just heading for viral spreading prefer the plattforms that share the best (just facebook again)