Build
Sessions
Resolve host-owned conversation keys, keep turns serialized, configure compaction and retention, and read the canonical transcript.
A Session is nvoken's durable conversation record. Most applications let the
first Invocation create it, then store the returned session_id beside their
own thread or ticket.
Create or resolve a Session
Pass a host-owned key when admitting the first turn:
{
"agent_key": "support",
"tenant_key": "acme",
"user_key": "user-481",
"session_key": "ticket-7391",
"idempotency_key": "ticket-7391:message-1",
"input": "Where is my order?",
"spec": { "model": { "provider": "anthropic", "id": "claude-sonnet-5" } }
}session_key is resolved within the effective tenant partition and Agent. It
does not have to be globally unique.
You can also call POST /v1/sessions before the first turn. That is useful when
a product needs a durable thread ID before it has a message. An unbound Session
gets its Agent from the first admitted Invocation.
Keep product labels in metadata
Session metadata is opaque host data such as a ticket ID, board key, or display title. nvoken returns it but never interprets it.
Set metadata at creation through session_options.metadata. Later, use
PATCH /v1/sessions/{session_id} with a merge patch: a string sets a key, null
removes it, and omitted keys stay unchanged.
Do not put authorization decisions in metadata. tenant_key and the caller's
credential establish isolation; metadata and user_key are filters only.
Serialize turns
A Session may have one queued, running, or waiting Invocation. The next
turn is rejected by default until that Invocation settles.
An SDK's bound Session also serializes calls inside one process:
const chat = agent.session({ sessionKey: "ticket-7391", tenantKey: "acme" });
await chat.text("My order number is 1842.");
console.log(await chat.text("What was my order number?"));The service rule remains authoritative across processes. Local serialization only avoids a predictable conflict in one client.
Compact provider context
Compaction is optional and must be chosen when the first Invocation creates the Session, because its policy is checked against that model:
await agent.invoke("Start a long research thread.", {
sessionKey: "research-42",
sessionOptions: {
compaction: { triggerTokens: "auto" },
},
});auto resolves to a token threshold based on the model's context window. You
can provide an exact threshold and an optional summary model from the same
provider.
Compaction changes only what nvoken sends to the provider. It does not edit or remove canonical messages. The resolved policy is visible on the Session, and summary usage is included in Session usage.
Set an idle retention window
Creation may include:
{
"session_options": {
"retention": { "ttl_seconds": 86400 }
}
}The allowed window is one hour to thirty days. It measures idle time, so every
admission and settlement moves expires_at forward. Automatic expiry skips a
Session with active work.
Omit retention for a conversation the user expects to find again. A short window fits scratch work or a one-shot structured task.
Read messages or drain changes
Use GET /v1/sessions/{id}/messages for ordinary paged transcript reads.
Use GET /v1/sessions/{id}/transcript when a worker needs a fixed-cut,
incremental drain. Continue with next_page_token until has_more is false,
then store resume_cursor for the next drain. New writes do not extend an old
page traversal forever.
The Session stream exposes the same transcript projection over SSE. See Streaming & recovery.
Delete with care
DELETE /v1/sessions/{session_id} immediately erases the Session and its whole
subtree. That includes Invocations, messages, ToolCalls, checkpoints,
compactions, provider artifacts, and undelivered notifications.
The operation is not a complete tenant or account deletion by itself. Stop new admission in the host, list every matching Session, and delete until the list is empty. Usage reports shrink when the underlying Invocation evidence is removed, so keep a separate billing ledger if usage affects invoices.
There is no Session fork endpoint. A branch is a new Session whose starting context is chosen by the host.