Learn more about different data types that can be used in a Jovo project.
Learn more about sessions and the request & response lifecycle here.
The Jovo Framework uses different concepts of data:
- Request Data: Only stored for this specific request.
- Session Data: Only stored for this session, across requests.
- User Data: Stored in a database, across sessions.
- App Data: Stored as long as the code is running.
Request data is written into the Jovo object (
this) and only stored for a specific request. This can be helpful if data is used across different methods (e.g. if Intent Redirects are used).
We recommend the following practice to store data in the Jovo object:
Session data (also called session attributes) stores data in the JSON response back to the platform, which can then be accessed in the next request (as long as the session stays active).
You can store elements into the session data like this:
States are also stored as session data/attributes.
The Jovo User object uses database integrations to persist user specific data across sessions.
The data can be stored like this:
App data is a special data type that stores data into the
app object, which exists as long as the server is running:
For example, this can be used for non-user-specific information that needs an API call that is not necessary to be executed at every request. By saving data into the
app object, the API call only needs to be done once while the server is running or the function is warm.
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 adding an
AccountLinkingCard to your response, which will be shown 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: