Sending Data
User data format for personalizing your documentation
When implementing authentication or personalization, your system returns user data in a specific format that enables content customization. This data can be sent as either a raw JSON object or within a signed JWT, depending on your handshake method. The shape of the data is the same for both.
User data format
Session expiration time in seconds since epoch. If the user loads a page after this time, their stored data is automatically deleted and they must reauthenticate.
exp
claim, which determines when a JWT is considered invalid. Set the JWT exp
claim to a short duration (10 seconds or less) for security. Use expiresAt
for the actual session length (hours to weeks).A list of groups that the user belongs to. Pages with a matching groups
field in their metadata will be visible to this user.
Example: User with groups: ["admin", "engineering"]
can access pages tagged with either the admin
or engineering
groups.
Custom data accessible in your MDX
content via the user
variable. Use this for dynamic personalization throughout your documentation.
Example:
Usage in MDX
:
With the example user
data, this would render as: Welcome back, Ronan! Your Enterprise plan includes…
User-specific values that will be prefilled in the API playground if supplied. Save users time when testing your APIs with their own data.
Example:
If a user makes requests at a specific subdomain, you can send { server: { subdomain: 'foo' } }
as an apiPlaygroundInputs
field. This value will be prefilled on any API page with the subdomain
value.
header
, query
, and cookie
fields will only prefill if they are part of your OpenAPI security scheme. If a field is in either the Authorization
or Server
sections, it will prefill. Creating a standard header parameter named Authorization
will not enable this feature.