---
title: "Contextual User Information"
slug: "contextual-user-information"
updated: 2026-09-03T18:19:38Z
published: 2026-09-03T18:19:38Z
canonical: "docs.developer.comcast.com/contextual-user-information"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.developer.comcast.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Contextual User Information

### Accessing contextual information about the user

The X1 Platform provides the following ways to securely retrieve information about a user, X1 Device, or account:

- Custom URL Parameters
- .info() X1 JavaScript API method

This document covers the use of Custom URL Parameters. The full X1 JavaScript API documentation can be found [App Requirements](/docs/app-requirements).

Custom URL Parameters must be configured by Comcast. Reach out to your partner manager for more information.

## Custom URL Parameters

This feature allows information to be passed to an X1 Application about the user or X1 Device as URL parameters.

### Using custom URL params

URL parameters generally take the form of `{CHARIOT:key}`. Chariot is an X1 Platform component that runs in the Comcast cloud. When a X1 Application is launched by a user, an instance of Chariot is started with the appropriate launch parameters.

The template key can be included in a number of different Chariot X1 App launch parameters:

- url
- urlComponents.query.key
- urlComponents.path
- urlComponents.fragment
- templateData
- templateDataRequestHeaders

### Available URL Parameters

#### X1 Environment Data

| Description | Possible Keys | Examples |
| --- | --- | --- |
| General purpose information about the X1 Device or environment. | zipCode^ language locale deviceHash† receiverId appId timeZone partnerId deviceCapabilities* | `http://my.url?zipCode={CHARIOT:zipCode}` `http://my.url/partners/{CHARIOT:partnerId}` |

^This is a restricted value. Restricted values are not availble to all apps. Please contact your partner manager for more information.

**deviceCapabilities* - All possible values for this template are listed under [deviceCapabilities()](/docs/devicecapabilities) . Complex objects are referenced using dot notation, eg. `{CHARIOT:deviceCapabilities.hdcp.supportedHDCPVersion}`. For all `deviceCapabilities` that are an array of values the template will be resolved as a comma separated values.

*†deviceHash* - A unique hash of the deviceId containing only the following characters: [a-z A-Z 0-9]

#### Parental Controls

| Description | Possible Keys | Examples |
| --- | --- | --- |
| If these templates are used, Chariot will look up the parental control settings for the user and pass them to the X1 App. The `restrictionLevel` is the lowest level that is locked. So if a user locks `tvpg`, that also means `tv14` and `tvma` are locked as well. The value passed in for `tvRestrictionLevel` will be `tvpg`. | `tvRestrictionLevel` `movieRestrictionLevel` | `http://my.url?restrictionLevel={CHARIOT:tvRestrictionLevel}` |

#### App Authentication Data

| Description | Possible Keys | Examples |
| --- | --- | --- |
| If this template is used, Chariot will look up the a previously stored auth token in Comcast's secure authentication store (called Auth Wallet) for the user, parse the response data to get the selected attribute and return it. | `appAuthData` `selected_attribute` | `templateDataRequestHeaders.Authorization = {CHARIOT:appAuthData.userAuthToken}` |

#### Mapped Data

Chariot is capable of mapping any template value to another value. For instance, if an X1 App has specific model strings that it uses, the mapping between X1 Platform models and X1 App models can be stored in the Chariot system and then the mapped value can be looked up when the template is dereferenced.

This is accomplished by prefixing any template key with `MAP_NAME/`, where `MAP_NAME` is a key that references a map of X1 Platform values to X1 App values.

#### Example

An X1 App can ask to store this map in the Chariot system:

```plaintext
   APP_MODELS
   pace_xg1 = appmodel1
   pace_xg1v3 = appmodel2
```

The app can then include the template `{CHARIOT:APP_MODELS/deviceCapabilities.deviceMakeModel}` in its URL. The template the might resolve `deviceCapabilities.deviceMakeMode` as `pace_xg1`, then see that it needs to map to `APP_MODELS`. The value that is actually returned is `appmodel1`.

#### Chariot App Launch Parameters

| Description | Possible Keys | Examples |
| --- | --- | --- |
| This is any value which is passed into Chariot as an X1 App launch config. | n/a | `http://my.url?mutePlayer={CHARIOT:mutePlayer}` `http://my.url?q={CHARIOT:search.query}` |

#### Arbitrary Data

| Description | Possible Keys | Examples |
| --- | --- | --- |
| This is a generic parameter that Chariot knows nothing about but was passed in as a launch parameter. The launch parameter must be prefixed with param. whereas the template key is not.The main use for this is storing business logic of a URL in a central configuration, then having different launch points pass in the parameter. This can also be accomplished with `urlComponents` in most cases. The only catch for `urlComponents` is that the clients doing the launching need to know the name of a query parameter which can be thought of needing to know business logic of the X1 Application. If the query parameter changes for the X1 App, then all the launch points need to change. With templating, just the centralized config needs to change. It is a small distinction, but templating provides extra flexibility. | n/a | `http://my.url?q={CHARIOT:myparam}` where `{"param.myparam":"value"}` is passed to Chariot when it is deeplinked into to launch the X1 App. |