Skip to main content
Version: 1.7.0

Add DVARA to an existing OpenAI-SDK app

The problem​

You have an application already calling OpenAI (or any provider behind an OpenAI-compatible SDK), and you need to put governance — policy enforcement, tamper-evident audit, PII redaction, cost attribution — in front of it. You don't want to rewrite the code. You don't want to migrate to a different SDK.

The approach​

DVARA's data plane speaks the OpenAI wire protocol. Every OpenAI-compatible SDK already supports overriding the base URL. Change one line — base_url — and every governance stage kicks in on call one, without touching the rest of the application.

Prerequisites​

  • A running DVARA instance. If you don't have one yet, follow the Quickstart.
  • A DVARA workspace and API key. Create them from DVARA Flightdeck.
  • An existing application using the OpenAI Python SDK, OpenAI JS SDK, or any OpenAI-compatible client.

The steps​

1. Swap the base URL​

Python:

from openai import OpenAI

# Before
# client = OpenAI(api_key="sk-openai-production-key")

# After
client = OpenAI(
    api_key="<your-dvara-api-key>",             # DVARA-issued, not the OpenAI key
    base_url="https://dvara.internal.example.com/v1",
)

# No other code changes — every existing request continues to work
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Summarise this ticket in two lines."}],
)

Node.js:

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: "<your-dvara-api-key>",
  baseURL: "https://dvara.internal.example.com/v1",
});

const response = await client.chat.completions.create({
  model: "gpt-4o",
  messages: [{ role: "user", content: "Summarise this ticket in two lines." }],
});

2. Confirm it on the wire before you look anywhere else​

The response is still an ordinary OpenAI chat completion — that is what makes this a drop-in — but two headers tell you DVARA handled it:

curl -i https://dvara.internal.example.com/v1/chat/completions \
  -H "Authorization: Bearer <your-dvara-api-key>" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-4o","messages":[{"role":"user","content":"Summarise this ticket in two lines."}]}'
HTTP/1.1 200
X-Trace-ID: f354bd1087a64bd6bf3bcff073139655
X-Cache: MISS
Content-Type: application/json
{
  "id": "chatcmpl-5654b316969d4c54b1549ac39b54b322",
  "object": "chat.completion",
  "created": 1787971119,
  "model": "gpt-4o",
  "choices": [
    {
      "index": 0,
      "message": {"role": "assistant", "content": "Customer reports a failed refund..."},
      "finish_reason": "stop"
    }
  ],
  "usage": {"prompt_tokens": 12, "completion_tokens": 5, "total_tokens": 17}
}

X-Trace-ID is the correlation key: the same value appears on the audit event, the cost record and the access log for this call, so it is what you quote in a support request. X-Cache tells you whether the response came from the semantic cache rather than the provider.

If you get a 401 instead, you changed the base URL and kept the old key. This is the most common way the retrofit goes wrong, because the request is otherwise valid and the SDK reports it as an authentication problem with the provider:

{
  "error": {
    "message": "Invalid API key.",
    "type": "authentication_error",
    "code": "invalid_api_key",
    "trace_id": "ae89f768e8ad4abfa305a381389e8033"
  }
}

The key must be the DVARA-issued one. The provider key stays on DVARA's side — which is the next step, and the point of the exercise.

3. Keep upstream provider keys on DVARA's side​

The OpenAI key stays in DVARA — stored in the workspace's provider credentials or in the gateway's environment. Application code never sees it, which is the whole point of moving it behind a governance gateway. See Credentials & BYOK for the workspace-scoped BYOK flow.

4. Verify governance is active​

Send one request, then check three places in DVARA Flightdeck:

WhereWhat you should see
Audit eventsA GATEWAY_RESPONSE event with your workspace ID, model, token counts, and (optionally) redacted prompt
Cost recordsA row under your workspace for the request, with provider + model + input/output tokens + USD cost
DashboardThe request counted in the workspace's aggregate metrics

If you don't see these, auth failed silently — the DVARA API key is wrong, or the workspace isn't active. Check the gateway access log for the HTTP 401 / HTTP 403.

What you just got​

With one line changed, every request from this application now goes through DVARA's pipeline before reaching OpenAI:

  • Policy evaluation — workspace-level YAML policies decide whether the request is allowed, logged-only, or blocked
  • PII detection and redaction — configurable per workspace; PII tokens can be blocked, redacted with reversible tokens, or just logged
  • Tamper-evident audit — every request and response is signed and chained, independent of what the application logs
  • Cost attribution — workspace + API key + model + tokens → per-workspace spend you can chargeback
  • Guardrails — injection detection, content filters, output schema validation if you enable them
  • Rate limiting + budget caps — per-workspace throttles and spend ceilings

The application code is unchanged. That's the point.

Next steps​

  • Canary a new model version — roll out gpt-4o → gpt-5 on a small traffic slice once DVARA is in the path
  • Attribute cost per workspace — if you host this app for multiple customers, wire each to its own workspace
  • DVARA headers — X-Trace-ID, X-Session-Id, and other headers for correlation across services
  • Structured outputs — response_format: json_schema keeps working; DVARA translates transparently for Anthropic and Bedrock
Last updated on