Request context - Averta

Request context gives Averta stable identifiers for runtime decisions. Without it, decisions still run, but debugging is worse. Provider wrappers accept the same three values in runtime-native casing.

JavaScript option	Python option
`conversationId`	`conversation_id`
`requestId`	`request_id`
`traceId`	`trace_id`

client = wrapOpenAI(client, {
  requestContext: {
    conversationId: "conversation_123",
    requestId: "request_456",
    traceId: "trace_789",
  },
});

client = wrap_openai(
    client,
    request_context={
        "conversation_id": "conversation_123",
        "request_id": "request_456",
        "trace_id": "trace_789",
    },
)

Field Semantics

Field	Use it for	Stability
`conversationId`	Group all turns in one user-agent conversation.	Same across related turns.
`requestId`	Identify one application request, turn, job, or model run.	New for each turn or job.
`traceId`	Connect Averta events to your logs, traces, or observability system.	Same as your tracing span or request trace.

If requestId or traceId is missing, the SDK generates one. It does not generate conversationId because only your app knows the conversation boundary.

Recommended Pattern

For a multi-turn agent, keep conversationId stable and rotate requestId per turn:

const requestContext = {
  conversationId: conversation.id,
  requestId: `turn_${turn.id}`,
  traceId: activeTraceId,
};

client = wrapOpenAI(client, {
  requestContext,
});

request_context = {
    "conversation_id": conversation.id,
    "request_id": f"turn_{turn.id}",
    "trace_id": active_trace_id,
}

client = wrap_openai(
    client,
    request_context=request_context,
)

Create a fresh wrapped client when request context changes. The wrappers store options on the wrapped client, and wrapping the same client twice is rejected.

Dashboard Debugging

Use request context to answer operational questions:

Question	Search by
What happened in this user conversation?	`conversationId`
Why did this specific turn fail?	`requestId`
How do Averta events line up with app logs?	`traceId`
Did production use the wrong policy?	API key prefix plus `requestId`

Common Mistakes

Reusing one requestId for every turn in a conversation.
Omitting conversationId for multi-turn agents.
Creating request context in logs but not passing it into wrapOpenAI(...), wrap_openai(...), or wrapAnthropic(...).
Wrapping one long-lived provider client once and expecting per-request context to change later.