In this section, you will learn how to deal with entities and slot values provided by your users, and also store and retrieve user specific data with the User class.

Introduction to User Input

If you're new to voice applications, you can learn more about general principles like slots and entities here: Getting Started > Voice App Basics.

We call user input any additional information your user provides besides an intent. On Amazon Alexa, input is usually called a slot, on Google Assistant/Dialogflow an entity or parameter.

How to Access Input

With the update to Jovo v1.0, we changed the way you can access input values. Please read more below, or take a look at our migration document.

There are two ways to get the inputs provided by a user: either by adding parameters to your handlers intent functions, or by using the getInput method.

Each input is an object which looks like this:

For example, if we want to access the value of an input name provided by the user, we can do so by using name.value.

Other parameters (like id or platform specific elements) can be found in the object as well.

Input as Parameter

You can access input by adding parameters directly to your intent.

For example, the sample voice app does it like this:

Two important things to consider when using this option:

  • The parameter names need to be the same as the slot/entity names on the respective developer consoles at Amazon and Dialogflow
  • The incoming names are matched to camelCase, for example given-name can be accessed with a givenName parameter.


You can either access the values of all user inputs with the getInputs method, or get specific values directly with getInput('inputName').


Similar to intentMap, there are cases where it might be valuable (due to naming conventions on different platforms or built-in input types) to map different input entities to one defined Jovo inputName. You can add this to the configuration section of your voice app:

Example: You want to ask your users for their name and created a slot called name on the Amazon Developer Platform. However, on Dialogflow, you decided to use the pre-defined entity given-name. You can now use an inputMap to match incoming inputs from Alexa and Google.

With this, you can use name as a parameter in your intent function:

User Object

Besides conversational parameters, there is also additional information that is not explicitly provided by a user, like which device they are using, or their ID. Learn more about different types of implicit user input in this section.

For retrieving and storing this type of information, the Jovo User Class can be used to create more contextual and adaptive experiences based on user specific data.

The user object can be accessed like this:

You can find more information here: App Logic > Data > User.


When you're using a local webhook (see jovo webhook), it's easy to use logging for debugging, like this:

For voice app specific debugging, Jovo offers some handy functions for logging incoming requests and outgoing responses.

You can enable logging by using the following:

This will enable both Request Logging and Response Logging, which can also be enabled separately. For this, see the sections below.

Log Requests

You can log the incoming JSON requests by adding the following configuration:

The result looks like this (data changed):

Request Logging Objects

As you can see above, the logs of a request are quite long and impractical, if you only need certain information. With requestLoggingObjects, you can limit the log output to specific objects.

The example above will reduce the log output to this:

Log Responses

You can log the outgoing JSON responses by adding the following configuration:

The result looks like this:

Response Logging Objects

Similar to requestLoggingObjects, you can limit the response logging output to specific objects, as well.

The example above will reduce the log output to this:

Persisting Data

Learn more about Sessions here: App Logic > Routing > Introduction to User Sessions.

If you want to store user input to use later, there is an important distinction to be made: Should the information only be available during a session, or be persisted for use in later sessions?

Session Attributes

For information that is only needed across multiple requests during one session, you can attach attributes to your responses. Learn more here: App Logic > Routing > Session Attributes.

Database Integrations

For information that is needed across sessions, you can use our user class together with our database integrations. Learn more here: App Logic > Data > User, Integrations > Databases.

Account Linking

To implement Account Linking in your voice application, you need two core methods.

The first allows you to prompt the user to link their account, by showing a card in the respective companion app:

The other method returns you the access token, which will be added to every request your skill gets, after the user linked their account:

For more information on Account Linking, check out our blogposts:

Comments and Questions

Any specific questions? Just drop them below. Alternatively, you can also fill out this feedback form. Thank you!

Join Our Newsletter

Be the first to get our free tutorials, courses, and other resources for voice app developers.