> ## Documentation Index
> Fetch the complete documentation index at: https://docs.averta.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Request context

> Correlate Averta decisions across conversations, requests, and traces.

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`        |

<CodeGroup>
  ```typescript TypeScript theme={null}
  client = wrapOpenAI(client, {
    requestContext: {
      conversationId: "conversation_123",
      requestId: "request_456",
      traceId: "trace_789",
    },
  });
  ```

  ```python Python theme={null}
  client = wrap_openai(
      client,
      request_context={
          "conversation_id": "conversation_123",
          "request_id": "request_456",
          "trace_id": "trace_789",
      },
  )
  ```
</CodeGroup>

## 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:

<CodeGroup>
  ```typescript TypeScript theme={null}
  const requestContext = {
    conversationId: conversation.id,
    requestId: `turn_${turn.id}`,
    traceId: activeTraceId,
  };

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

  ```python Python theme={null}
  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,
  )
  ```
</CodeGroup>

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.