Reference

The names you look up most often, in one place. The background for each concept is in Core concepts and Event design.

Gateway request headers

Header	Role
Authorization: Bearer ck-abto-…	Identifies the project with your ABTO Calling Key. Required.
x-abto-key-openai etc.	The API key for the model provider you contract with directly. Required.
x-abto-feature-id	The feature ID. Required; requests without it are rejected.
x-abto-device-id	The user device identifier. Optional — the call and its call-level analytics still work, but the request is left out of behavior joining, sticky assignment, and user-level metrics.

Gateway response headers

Header	Role
x-abto-request-id	Identifies the call you just made and links individual interactions to it — remember this one if you remember only one.
x-abto-attempt	A 1-based ordinal for the attempt that produced this response.
x-abto-provider	The provider actually assigned. The same model ID can span providers, so the response body alone cannot recover it.
x-abto-error-source	Where a failure came from — provider, transport, or internal. Absent on admission rejections raised before exposure, so its absence is itself a signal.

Browser system events

SDK name	Analytics event_name
$pageview	pageview
$pageleave	pageleave
$ai_prompt_submitted	llm_prompt_submitted
$ai_response_rendered	llm_response_rendered
$ai_response_interacted	llm_response_interacted

Key identifiers

Name	Meaning
uuid / event_id	Event identifier the SDK generates automatically
device_id	Browser installation identifier. The primary axis joining product behavior to AI usage
$user_id	Logged-in user identifier attached via identify (optional)
session_id	Logical session identifier
$pageview_id	Identifier for a page/route observation span
$feature_id	Feature ID (a.b.c). The same value the Gateway call carries in x-abto-feature-id
$request_id	AI request identifier issued by the gateway. The correlation key joining a call to its response interactions
$response_id	Individual AI response identifier