Reference
Integrations
Connect beliefstate to your active web applications, orchestration flows, and agent run cycles using native framework wrappers.
FastAPI Integration
The FastAPI middleware extracts session IDs from request headers and sets session context automatically — your endpoint handlers need no changes.
| Parameter | Type | Default | Description |
|---|---|---|---|
app |
ASGIApp | required | The target FastAPI application instance. |
header_name |
str | "X-Session-ID" | The HTTP header key utilized to look up session identifiers. |
Context Propagation Mechanics
The middleware manages concurrent request execution states using context variables:
- Lookup — Middleware intercepts incoming headers and extracts the session identifier value, executing
session_context.set(session_id). - Propagation — The context propagates through the async call chain, enabling trackers to retrieve state without explicit parameters.
- Cleanup — A
finallyexecution block executessession_context.reset()to restore initial empty contexts.
Testing Locally
Trigger requests with target headers to verify session propagation:
If X-Session-ID header is missing, the session defaults to 'default' — all requests without a header share one belief store. Always send a session header in production.
Flask Integration
For Flask WSGI backends, beliefstate supports request context extraction via WSGI middleware or lifecycle hooks.
Middleware Parameters
| Parameter | Type | Default | Description |
|---|---|---|---|
app |
WSGIApp | required | The underlying WSGI application instance. |
header_name |
str | "X-Session-ID" | HTTP header key holding session identifiers. |
Hook Parameters
| Parameter | Type | Default | Description |
|---|---|---|---|
app |
Flask | required | The Flask application instance. |
header_name |
str | "X-Session-ID" | HTTP header key holding session identifiers. |
Middleware vs Hooks — either works. Middleware recommended for consistency with other frameworks.
Generic ASGI Middleware
Works with Starlette, Litestar, Quart, or any ASGI-compatible framework.
| Parameter | Type | Default | Description |
|---|---|---|---|
app |
ASGIApp | required | The target ASGI application instance. |
header_name |
str | "X-Session-ID" | Case-insensitive header key indicating session ID. |
HTTP header keys are processed case-insensitively, complying with the RFC 7230 specification guidelines.
LangChain Callback
Hooks into LangChain's on_llm_end lifecycle event.
| Parameter | Type | Default | Description |
|---|---|---|---|
tracker |
BeliefTracker | required | The active BeliefTracker tracking instance. |
You must set session_context before invoking the chain. LangChain callbacks don't have access to HTTP request headers.
Callback Lifecycle
The callback coordinates execution during the run cycle:
- Callback intercepts output text and input prompt.
- Grabs
session_idfromContextVar. - Dispatches background tracking task.
LlamaIndex Callback
Registers a callback handler with LlamaIndex's callback manager to track llama-index execution queries automatically.
| Parameter | Type | Default | Description |
|---|---|---|---|
tracker |
BeliefTracker | required | The active BeliefTracker tracking instance. |
Registers globally via Settings — all LLM calls in the process are tracked automatically.
OpenAI Assistants Observer
Polls a run to completion, then extracts beliefs from the full thread conversation in bulk.
| Parameter | Type | Default | Description |
|---|---|---|---|
tracker |
BeliefTracker | required | The active BeliefTracker tracking instance. |
client |
AsyncOpenAI | required | OpenAI client connection client. |
thread_id |
str | required | OpenAI assistant thread key. |
run_id |
str | required | Assistant run session ID. |
session_id |
str | required | Belief state session context key. |
Difference from @tracker.wrap — the observer processes the full thread after the run completes, not turn-by-turn.
Error Handling in Integrations
BeliefState is built to operate as a non-blocking tracking layer. Under-the-hood, all integrations wrap execution segments to isolate exception contexts and safeguard your primary application flow.
What always happens
- User receives LLM response
- Error is logged as warning
- Session context is cleaned up
What never happens
- Exception propagates to your app
- User request fails due to tracking error
- Belief store left in inconsistent state