Enabling adaptive content

Choose an authentication method to pass user data to GitBook.

To start customizing your documentation experience for your readers, you'll need to enable adaptive content and decide how your visitor data is passed to GitBook. This lets your site's content dynamically adapt based on who's viewing it.

Enable adaptive content

Before you’re able to pass user data to GitBook, you’ll need to configure your site to use adaptive content.

Head to your site’s settings, and enable Adaptive content from your site’s audience settings. Once enabled, you’ll get a generated ‘Visitor token signing key’, which you’ll need in order to continue the adaptive content setup.

Enable adaptive content in your site’s Settings

Set your visitor schema

After enabling adaptive content, you’ll need to define a schema for the types of claims you expect GitBook to receive when a user visits your site.

The visitor schema should reflect how these claims are structured when sent to GitBook.

For example, if you expect a visitor to potentially be a beta user in your product, you would set a visitor schema similar to:

{
  "type": "object",
  "properties": {
    "isBetaUser": {
      "type": "boolean",
      "description": "Whether the visitor is a Beta user."
    }
  },
  "additionalProperties": false
}

This will also help you use autocomplete when configuring your claims in the condition editor. Visitor schemas only support the following types:

Strings

Read claims being passed in as strings.

GitBook accepts dynamic strings, meaning you can dynamically pass string data — such as a user’s name, developer tokens, and more.

Strings can also contain an optional enum key, which allows you to restrict the data that is received by GitBook to one of it’s set values.

{
  "type": "object",
  "properties": {
    "language": {
          "type": "string",
          "description": "The language of the visitor",
          // Optional enum property
          "enum": [
            "en",
            "fr",
            "it"
          ]
  },
  "additionalProperties": false
}

Dynamic strings (strings defined without an enum key) are only accepted for inline expressions. Conditional expressions for visibility of elements (pages, sections, blocks) only work with strings defined with enum keys.

Booleans

Objects

Set an unsigned claim

Unsigned claims are a specific type of claim that identifies claims coming through that might not be signed by a client application. It is required to set claims in your visitor schema as unsigned if you are passing claims through URL parameters, unsigned cookies, and feature flags.

If you intend to work with unsigned claims, you will need to declare the claims you are expecting in the schema under an “unsigned” prop alongside your signed claims.

{
  "type": "object",
  "properties": {
    "isBetaUser": {
      "type": "boolean",
      "description": "Whether the visitor is a Beta user."
    },
    // Add unsigned claims
    "unsigned": {
      "type": "object",
      "description": "Unsigned claims of the site visitor.",
      "properties": {
        "language": {
          "type": "string",
          "description": "The language of the visitor",
          // Optional enum property
          "enum": [
            "en",
            "fr",
            "it"
          ]
        }
      },
      "additionalProperties": false
    }
  },
  "additionalProperties": false
}

Pass visitor data to GitBook

GitBook provides different ways to pass visitor data to adapt your site's content. After defining your schema, you’ll need to decide how you want to pass your visitor data to GitBook.

Cookies

Pass visitor data into your docs through a public or signed cookie.

URL

Pass visitor data into your docs through URL query parameters.

Feature flags

Pass visitor data into your docs through a feature flag provider.

Authenticated access

Pass visitor data into your docs through an authentication provider.