user_id (and customer_id) is strongly recommended — it scopes the in-process anticipation cache to that user so bundles prefetched for one user can never be served on another user’s lookup. These will become required in a future release.
Parameters
The conversation to fetch context for. Must be a valid UUID (e.g.
str(uuid.uuid4())) — the same id you used when recording the conversation’s messages.Optional list of query strings to bias retrieval. When omitted, the most relevant recent context is returned.
Maximum number of items to return per context type.
Context types to include. Defaults to all available types (facts, preferences, episodes, emotions, temporal events).
Retrieval mode — the retrieval axis (
fast vs accurate) of Retrieval Modes:"fast"— direct query, lower latency. Best for in-the-loop prompt assembly."accurate"— LLM-enhanced queries, higher quality at higher latency. Best when you can afford the extra latency.
External user id. Strongly recommended — scopes anticipation cache lookups to the right user and avoids deriving scope from a not-yet-written conversation row.
External customer id, forwarded alongside
user_id for the same scoping reason. Required on B2B; auto-resolved on B2C — see B2C vs B2B.Returns
AContextResponse containing the retrieved context.
Facts learned about the user during this conversation.
Stated or inferred preferences relevant to this conversation.
Episodic memories tied to this conversation.
Detected emotional signals.
Time-anchored events relevant to the conversation.
Compacted/summary context for this conversation, when available.
Correlation id, source (
cache or cloud), TTL, and retrieval timestamp.Example
Raises
InvalidInputError— whenmodeis not"fast"or"accurate".AuthenticationError— when the API key is missing or invalid.NetworkError— when the SDK cannot reach Synap.