Skip to main content

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, immutable 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 tenant and API key. Create them from DVARA Flightdeck or POST /v1/admin/tenants via the Automation API.
  • 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. Keep upstream provider keys on DVARA's side​

The OpenAI key stays in DVARA — stored in the tenant'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 tenant-scoped BYOK flow.

3. Verify governance is active​

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

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

If you don't see these, auth failed silently — the DVARA API key is wrong, or the tenant 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 — tenant-level YAML policies decide whether the request is allowed, logged-only, or blocked
  • PII detection and redaction — configurable per tenant; PII tokens can be blocked, redacted with reversible tokens, or just logged
  • Immutable audit — every request and response is signed and chained, independent of what the application logs
  • Cost attribution — tenant + API key + model + tokens → per-tenant spend you can chargeback
  • Guardrails — injection detection, content filters, output schema validation if you enable them
  • Rate limiting + budget caps — per-tenant 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 tenant — if you host this app for multiple customers, wire each to its own tenant
  • 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