Introducing the long awaited CanFulfillIntentRequest type!

Up until now, Alexa users usually have to use the skill name when invoking a third party skill. For instance, “Alexa, ask 21 Dayz what my goals are for today?” In this example, “21 Dayz” is the skill name. If a user tried to ask “Alexa, what are my goals for today,” without it, they would typically get “Sorry, I don’t know that one”.

Now with the new CanFulfillIntentRequest type, you can include your skill in a pool of possible skills that can handle name-free skill interactions. This new request type is backward-compatible and can work with your existing skill with some minor tweaks, specifically handling the CanFulfillIntentRequest type similar to how you handle the other request types. For example, say you have a simple switch statement like…

switch (req.type) {
  case "LaunchRequest": 
    processLaunchRequest(req); break;
  case "IntentRequest": 
    processIntentRequest(req); break;
  case "SessionEndedRequest": 
    processSessionEndedRequest(req); break;
}

In this case (pun intended), you add another case for “CanFulfillIntentRequest” for example…

switch (req.type) {
  case "LaunchRequest": 
    launchRequest(req); break;
  case "CanFulfillIntentRequest": 
    canFulfillIntentRequest(req); break;
  case "IntentRequest": 
    intentRequest(req); break;
  case "SessionEndedRequest": 
    sessionEndedRequest(req); break;
}

Or if you are using the Alexa Skills Kit SDK, then you can implement the “onCanFulfillIntent” interface. Whichever route you take, in your function, in our case here, we do something like the following…

function canFulfillIntentRequest (req) {
  var intentName = req.intent.name;
  var slots = req.intent.slots;

  //TODO: validate if your skill can handle 
  //this intent name and any provided slots here

  return {
    version: "1.0",
    sessionAttributes": {...},
    response": {
      canFulfillIntent: {
        canFulfill: "<YES, NO or MAYBE>",
        canFulfillSlotsResponse: {
          <SLOT-NAME>: {
            canUnderstand: "<YES, NO or MAYBE>",
            canFulfill: "<YES or NO>"
          }
        }
      }
    },
    outputSpeech:{...},
    card:{...},
    reprompt:{...},
    directives:[...],
    shouldEndSession:false
  };
}

Basically what’s happening in the code sample above is, first, Alexa sends an HTTP post request to your endpoint with the request type set to “CanFulfillIntentRequest”. This request includes an intent name and possibly some slots as well. In your canFulfillIntentRequest function, we want to validate if we can indeed handle the intent name and any slots provided but we do not, and this is very important, do not execute the actual intent! All we want to do is make sure we can indeed handle it then respond back to Alexa with either YES or NO specified for the “canFulfill” property as well as set “canFulfill” to YES or NO for all slots under “canFulfillSlotsResponse”. The reason why we do not want to execute the actual intent is because Alexa will send out multiple “CanFulfillIntentRequest” to multiple third-party skills (currently 2 skills at a time) and will pick one skill after it’s collected the canFulfillIntentResponse back. So imagine if all those skills kicked off a pizza ordering process or turned off lights for example, not good. Only the chosen skill should execute the actual intent.

As for the other property in “canFulfillSlotsResponse” called “canUnderstand”, you set this to YES if your skill has a perfect match or high-confidence match. Set to NO if it can’t match the value. Pretty straight forward.

Call me… MAYBE?

Here’s an interesting one, instead of YES or NO on some of those “canFulfill” and “canUnderstand” properties (I bet you were wondering why not true or false right?), you can also specify “MAYBE”.

Setting MAYBE on “canUnderstand” basically let’s Alexa know that your skill has a partial match instead of an exact match as in the case of partial or fuzzy search results. As for “canFulfill” at the “canFulfillIntent” level, MAYBE instructs Alexa that your skill has might be able to process the request. This could be due to some slots being set to YES and others to MAYBE or if you need to prompt for account linking or fulfill required slots or some other multi-turn conversation requirement.

What Else?

If you are using the latest ASK CLI tools for your skills, check out the Quick Start Guide to get started.

To learn more about the specification, check out the “Name-Free Interaction for Alexa Skills” page.

Lastly, if you haven’t already, read the official Beta announcement here.

Once the feature is out of public beta, I’ll circle back and update this post with any relevant updates.

If you have any questions, feel free to reach out to me anytime or any one of the Alexa Champions or Evangelists in Slack.

Happy coding!

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInShare on Reddit