# Sessions

Sessions describe a means of conceptualizing how Airkit keeps track of where users are within the flow of an application, as well as what they've done, entered, or requested in the process.

Whenever someone uses an Airkit app, they're working within an individual **Session**, a term in Airkit used interchangeably with "Journey". By automatically distinguishing each **Session** as a separate entity, Airkit makes it possible to gather information regarding how a user is engaging with an application, even if nothing else is known about the user themselves.

### Defining a Session

An Airkit **Session** starts when a user first begins to go through the flow of an app. This can happen in many different ways, but regardless of how a **Session** starts, it spans all of the user's interactions with that app, across all relevant channels, as long as the app has some way of recognizing the **Session**. This is done by associating a **Session** with unique identifiers. By default, Airkit provides the first identifier automatically: as soon as a Session begins, it is assigned a unique ID (the "session ID") as an identifier. This allows every **Session** to be immediately considered as its own separate entity, even if nothing else is known about the person embarking on it.

<details>

<summary>Where is the session ID stored?</summary>

\


The session ID is an automatically-created global variable, accessible as `session.id`. It is stored as a [string](../variable-data-types/the-text-variable-data-type).

For more on what session-level variables are and now they are used in Airkit, see documentation on [Variable Namespaces](../working-with-data/working-with-data-overview/variable-namespaces). For more on automatically-created variables, see [Standard Journey Data](../working-with-data/working-with-data-overview/standard-session-data).

</details>

If an app is sufficiently simple, automatically-assigned identifiers might be the only pieces of data associated with **Sessions** in that app. Similarly, a user might exit an app before providing any information that might serve as unique identifier. In both cases, it is still valuable to keep track the Session via its default identifier, for the purposes of data analytics if nothing else. You might want, for instance, to compare the number of **Sessions** started with the number of **Sessions** completed.

A single **Session** can span multiple channels by collecting relevant information and storing it in the form of identifiers. The exact nature of this relevant information varies, though emails and phone numbers are among the most common. If a **Session** begins with a user making an appointment via a web app, and then continues through the user getting a confirmation text, this is made possible only because the user's phone number was in some way tied to their **Session**. It wouldn't work otherwise – a phone number is required to receive a confirmation text, and if you send one, you want to ensure it's precisely confirming the appointment that was made online.

Identifying a **Session** by information known by the user also allows the user to pick up their **Session** where they left off should they leave in the middle. This is technically possible even when a **Session** is identified only by automatically-assigned IDs. For example, in the case of web apps, an initial identifier is stored in the URL path. (For security reasons, this identifier is **not** the same as the session ID.) If a user records the URL path associated with the **Session** they started – which is, critically, distinct from the Starting Link they went to in order to start their **Session** in the first place – they can resume their **Session** where they left off. However, if the user did not take note of the identifier in the URL path before exiting the web app, as is more likely the case, they will have no way of finding it out, and will therefore not be able to access that initial **Session** upon their return. They will be forced to start a new **Session** and repeat any aspects of it that they have already gone through.

<details>

<summary>What is the difference between a URL that resumes a Session and URL that begins a Session?</summary>

\


A Starting Link triggers the start of a **Session**. It can be used any number of times to begin any number of **Session**.

A Journey Link leads to a web page associated with an existing **Session**. It is capable of doing so because it contains a unique **Session** identifier in the URL path.

Upon navigating to a Starting Link and beginning a **Session**, the change from Starting Link to Journey Link will be reflected in the address bar of the web browser, as an identifier becomes part of the path parameters. (If you want to send someone a link to an Airkit app, be mindful of which URL you are sending. You cannot send someone a Starting Link by copy/pasting the URL from your address bar.)

Journey Links can be sent via reminder texts, prompting users to return to a half-finished **Session** to finish what has been started without loosing previous progress. For more on how this is done, see [Linking to Sessions](sessions/linking-to-sessions).

</details>

### Starting a Session

A **Session** starts whenever a user begins engaging with or being engaged by an Airkit app; this is when they are automatically assigned a unique ID as an identifier. You can start a **Session** upon a potential user clicking a link, sending a text message, or calling a phone number. A **Session** might also start when an API is triggered. Deciding how uses might begin a Session is done in the [Triggers Builder](../studio/studio/builder-bar/triggers-builder).

A single app might allow users to begin their **Sessions** through it via multiple channels. While each individual **Session** can only begin once, different users accessing the app might begin their interactions with it – and thus their **Sessions** – in different ways. An app might, for example, allow users to begin their **Sessions** via either sending a text or making a phone call.&#x20;

For a more detailed discussion on how to start Sessions from multiple channels, check out [Texting Journey Links](../sms/texting-journey-links).

### Ending a Session

Sessions don't last forever. By default, a **Session** ends after thirty days, although this default can be changed in [Settings](../studio/studio/builder-bar/settings), modified dynamically with the [Extend Session Expiration Time Action](../actions/the-extend-session-expiration-time-action), or overridden by the [End Session Action](../actions/the-end-session-action). The existence of this default is largely a matter of efficiency. Consider, for instance, cases where a user accidentally exits an app before reaching the end or providing any information that might serve as unique identifier. If the only way to end a **Session** was by explicitly ending it once the user had successfully completed what they set out to do, this **Session** would remain active but untouchable, in limbo, forever. With this default expiration, it only stays in this limbo for thirty days.

Once a **Session** is over, a user cannot return to it; if they access the app again, they will begin a **Session** anew.
