Try Gemini 1.5 Pro, our most advanced multimodal model in Vertex AI, and see what you can build with a 1M token context window. Try Gemini 1.5 Pro, our most advanced multimodal model in Vertex AI, and see what you can build with a 1M token context window.

Sessions

A session represents a conversation between a Dialogflow agent and an end-user. You create a session at the beginning of a conversation and use it for each turn of the conversation. Once the conversation has ended, you discontinue using the session.

You should not use the same session for concurrent conversations with different end-users. A session remains active and its data is stored for 30 minutes after the last request is sent for the session.

Each session is determined unique by a session ID generated by your system. You create a new session by providing a new session ID in a detect intent request and other session methods. A session ID is a string of at most 36 bytes in size. Your system is responsible for generating unique session IDs. They can be random numbers, hashed end-user identifiers, or any other values that are convenient for you to generate.

Check the Regionalization documentation for information about the Location ID value in the session name.

Long-lasting sessions

By default, Dialogflow maintains the session data for 30 minutes. There are two ways to extend the lifetime of the sessions:

(Preferred) Set session TTL using QueryParameters.session_ttl. The maximum allowed value is 24 hours.
You can revive the previous session state by setting QueryParameters.current_page and QueryParameters.parameters in DetectIntentRequest.

An example workflow looks like:
1. End-user talks with the agent under session A.
2. Your code records the state associated with session A returned in the API response, namely QueryResult.current_page and QueryResult.parameters.
3. End-user stops interacting with the agent after 50 minutes.
4. End-user talks with the agent again.
5. Your code sends the end-user input, together with the previously recorded QueryParameters.current_page and QueryParameters.parameters in the request, to detect intent with the previous session state. You do not need to use the same session ID as used by session A.
Note: Handler call stack will not be revived with this approach.

References

For information on session pricing, see the pricing page.

For more information on sessions:

Select a protocol and version for the Session reference:

Protocol	V3	V3beta1
REST	Session resource	Session resource
RPC	Session interface	Session interface
C++	SessionsClient	Not available
C#	SessionsClient	Not available
Go	SessionsClient	Not available
Java	SessionsClient	SessionsClient
Node.js	SessionsClient	SessionsClient
PHP	Not available	Not available
Python	SessionsClient	SessionsClient
Ruby	Not available	Not available

Training

GitHub export/restore