Skip to main content
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 optionPython option
conversationIdconversation_id
requestIdrequest_id
traceIdtrace_id
client = wrapOpenAI(client, {
  requestContext: {
    conversationId: "conversation_123",
    requestId: "request_456",
    traceId: "trace_789",
  },
});

​
Field Semantics

FieldUse it forStability
conversationIdGroup all turns in one user-agent conversation.Same across related turns.
requestIdIdentify one application request, turn, job, or model run.New for each turn or job.
traceIdConnect 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. 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,
});
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:
QuestionSearch 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.