I’m trying to create an Alexa capability that creates reminders without user voice invocation. To achieve this Alexa suggested to use “Out of session” interaction event i.e Skill Messaging API (https://api.amazonalexa.com/v1/skillmessages/users/{userId}), as you can see in the API we need to pass the user Id, In order to get the user Id Alexa suggest to do first account-linking, once linking is done we’ll get the user profile access including userId. Now, after hitting the Skill Messaging API with received userId, it returns
{type:”not_found”, a message ”invalid user Id”}.
Not sure where am I going wrong. Has anyone phase the same problem.
In the request shown next, set HOST to one of the following, depending on the user's region: api.amazonalexa.com, api.eu.amazonalexa.com, or api.fe.amazonalexa.com
Related
Within a custom Alexa skill hosted as a lambda service, I need to call an external API with an API key, that changes for each device. So I can't put the URL or the API Key hard-coded into the skill's code.
Whats the best practice to store user settings locally like an API Key for an Alexa skill? I tried to create an intent, where the user can dictate e.g. the API key, but it doesnt really work quite well and is not that user friendly. Unfortunately, I dindt find a way to create some sort of user preferences site, that might be accessabble for example through the Alexa app on the connected iPhone.
Each request comes with a User ID that uniquely identifies the owner of the device. I use that as a filename for an S3 bucket, retrieving that json file on my Launch intent and storing the info in the session vars. You can store anything you like in the S3 file and retrieve it per user.
There is no way to save any info without writing the code to do so. When the skill is first loaded, all session vars are empty. You need to write code to use the user id to lookup necessary info.
New to Alexa skills in general. Developing an application where the state of an Alexa skill is determined by other means than voice interaction. So let's say for instance it is a weather skill. I understand I could access a weather service from the skill intent handler to retrieve the "weather state", but I wonder if there is a way for - in this example - the weather station, to POST the state of the weather to the skill and have the skill store it as a (global, user independent) state variable.
This would save me having to build a second webservice where i would maintain state information.
I have seen the Messaging ability of skills, but I'm not sure if that is the right thing to use for what i want.
I think you need this Proactive Events API
You can use the Proactive Events API to send events to Alexa. The events represent factual data that might interest a customer. Upon receiving an event, Alexa proactively delivers the information to customers who have chosen to receive these events ...
Because customers can choose to be notified of events from your skill,
they are never surprised to receive proactive messages from Alexa.
With this API, you can send a personal customer-specific event, which
results in a notification for a single customer. Alternatively, you
can send a broadcast event, which triggers notifications to all
customers who have chosen to receive notifications from your skill.
For example, a weather skill can send a single weather alert, which
Alexa then delivers to all interested customers.
There is a demo in Javascript
After I figured out how easy it is to set up an EB webservice and build a simple API using Node for the ASK lambda function to fetch data from, I guess this is a better approach. I might even replace the ASK lambda function with an EB Node service that does both the skill backend and the persistent storage in one.
I am developping an Alexa Skill within the one the user has to provide a serie of answers to my backend (node.js) in order to get the right result. I would like to send this result by email.
Is it possible to retrieve the user's email through the API put at disposal by AWS using the Dialog.delegate method?
Thanks !
There is no built in method can get you the current user email id or any personal info.
But with authentication you can. See this blog post. You'll need to create an Amazon App and link it to your amazon skill using Account Linking. For the first time when you ask for the email, user has to accept access with their Alexa app. You can then save this email in your DB for future purposes. This is a long but recommended method.
The simplest method: Whenever the game is finished you can manually ask the user for email address. But Alexa may not recognize email address spoken by users properly and might break your app. I don't know, but maybe Alexa will reject your app for asking personal info this way!
I have an alexa skill and a website. I need to send requests from the alexa skill to change a certain variable on a website.
for examble, I have a name on the website lets say "michael", I want to be able to change that name to "zack" from alexa.
Alexa skill SDK allows you to perform remote calls to third-party APIs.
In your case, you can implement an API endpoint to change that field. Then you can call that endpoint with the data you need.
You can capture the name your user has been said.
By doing that, you would need to think how you will authenticate the user. Basically, you need to know how to match the user who is using Alexa with the user on your website. I don't think you want to change the name for the random user.
The scenario is that users of web application can purchase digital items. The web application will use Paypal Instant Payment Notification.
The IPN protocol consists of three steps:
PayPal sends your IPN listener a message that notifies you of the event
Your listener sends the complete unaltered message back to PayPal; the message must contain the same fields in the same order and be encoded in the same way as the original message
PayPal sends a single word back, which is either VERIFIED if the message originated with PayPal or INVALID if there is any discrepancy with what was originally sent.
Let's say it's VERIFIED, how could I know who have completed the transaction or purchased the item (user of the web application) if the user used other email address in his/her paypal? I have stored the email address of the user in session but what if he/she have different paypal email? Paypal email is included in IPN message.
For other details, maybe not useful, the application is written in Struts2 in Google-App-Engine.
You'll need a way to correlate the IPN data coming back with the user. Either by asking them to provide their paypal email or using the username/password generation facility in the IPN service. Here is a somewhat inelegant but functional approach:
When the IPN comes in off the wire, persist the paypal generated username/password and payer_id (in perhaps the datastore).
If you can't correlate by email, then when the user comes back to your site request that they enter the username/password generated from paypal's site once (just to correlate).
Lookup the username/password and then correlate their userid from the UserService back to the payerid.
The reason to use IPN is for subscription services as you can get IPN messages when the subscription is terminated, cancelled, or when payments come in (for an account that stopped paying).
The most important thing to think about is how to correlate a user of your site back to the payer_id (or even payer_ids in some cases) that are used to pay for the services they are using.
On another note, I wouldn't use the session to store information for IPN callbacks, those actually can take a LONG time sometimes (say when the x.com conference is on and everyone is hammering paypal).
If you have a running application or a better description of the look & feel, I might be able to come up with a more elegant suggestion. Let me know if this helps at all.
Why don't you use PayPal's express checkout? This way you negotiate server2server a token and then you can check with PayPal the result of that token on user's return.
If users are buying directly from your application it's easier to implement.
And I think it'is more robust than the method you're using (I never heard of it before :D )