SDK & Framework Integrations

DVARA is an AI governance platform — Policy-as-Code, immutable audit, PII redaction, agentic governance, and cost attribution under one control plane — with a fully OpenAI API-compatible data plane. Any SDK or framework that supports the OpenAI chat completions API works with DVARA by pointing at the gateway's base URL. No custom SDK required, and governance kicks in on the first request.

Pick your language

Jump to the integration guide for your stack — every page shows the full round-trip (request + response + observable effect in the DVARA Flightdeck):

• Python SDKs — OpenAI, Anthropic, AWS Bedrock, Google GenAI, LiteLLM, LangChain, Pydantic AI
• JavaScript / TypeScript SDKs — OpenAI JS, Anthropic JS, Vercel AI SDK
• Java SDKs — OpenAI Java SDK, Spring AI, LangChain4j
• Additional OpenAI-compatible providers — long-tail providers that aren't built in as first-class translators: Fireworks AI, Together AI, Perplexity, vLLM hosts, ERNIE / Wenxin, and any future OpenAI-compatible upstream. (Qwen, DeepSeek, Moonshot, ChatGLM, and Grok are first-class — see the full provider list on the additional-providers page.)
• DVARA-specific headers — X-Trace-ID, X-Session-Id for correlation across SDKs
• Migration guide — moving from direct provider access or another gateway
• Troubleshooting — common 4xx / 5xx errors and their fixes

Quick reference

The only change any of these SDKs need is the base URL. Everything else — the request shape, streaming semantics, tool-calling, structured output — stays the same.

SDK / Framework	Language	Config change
OpenAI SDK	Python	base_url
OpenAI SDK	JavaScript / TS	baseURL
OpenAI SDK	Java	.baseUrl() on the client builder
Anthropic SDK	Python	base_url + model prefix
Anthropic SDK	JavaScript / TS	baseURL + model prefix
AWS Bedrock SDK	Python	Switch to OpenAI SDK
Google GenAI SDK	Python	Switch to OpenAI SDK
LiteLLM	Python	api_base
LangChain	Python	openai_api_base
Pydantic AI	Python	base_url on OpenAI provider
Vercel AI SDK	JavaScript / TS	baseURL on createOpenAI()
Spring AI	Java	spring.ai.openai.base-url
LangChain4j	Java	.baseUrl()
Additional providers	any	Register a custom provider + OpenAI SDK base_url

Prerequisites

All examples on the language pages assume:

• DVARA is running at http://localhost:8080
• A tenant and API key have been created (see Quickstart)
• The target provider is configured in DVARA (e.g. OPENAI_API_KEY set)

Replace your-dvara-api-key with your actual DVARA API key throughout.

Supported endpoints

Every request from every SDK ultimately lands on one of these public Data Plane paths. The OpenAI-compatible shape means any SDK that speaks POST /v1/chat/completions on the vendor endpoint works against DVARA without change.

Endpoint	Purpose
POST /v1/chat/completions	Chat (all models, streaming, tools, structured output)
POST /v1/completions	Legacy text completion (wraps chat internally)
POST /v1/embeddings	Embeddings — used by RAG pipelines and semantic search
GET /v1/models	Live-queries every registered provider and returns a merged list with capabilities (streaming, vision, tools, structured output, max context tokens)
POST /v1/budget/estimate	Pre-flight budget check — returns estimated cost, remaining budget, and would_exceed_budget. Useful before long-running batch jobs so a client can surface a cap warning to the user instead of failing mid-run.
POST /v1/webhooks/actions/{action}	Approval-gate callback for MCP human-in-the-loop flows. Not called from the OpenAI SDK — receives a signed token from an approver clicking through a webhook link. Listed here for completeness.

Full request and response schemas, along with a Try it panel that executes real calls against a DVARA instance, live in the Data Plane API reference. The admin endpoints (tenants, routes, policies, budgets, credentials) have their own reference at Automation API — you'll rarely hit those from an SDK, but they're what your Terraform / CI pipeline calls.

Observability endpoints

These are separate from the request path. Every DVARA instance exposes them so your monitoring stack can scrape health and metrics:

• GET /actuator/health — Liveness summary (anonymous; good for liveness from any SDK). Sub-paths /actuator/health/liveness and /actuator/health/readiness are also anonymous, intended for Kubernetes probes.
• GET /actuator/info — Build info (app.*, build.*); also anonymous, useful for version discovery.
• GET /actuator/gateway-status — Rich gateway status (providers, routes, license, warnings). Requires Authorization: Bearer $DVARA_ACTUATOR_API_KEY — intended for operator tooling, not client SDKs.
• GET /actuator/prometheus — Prometheus scrape endpoint. Requires Authorization: Bearer $DVARA_ACTUATOR_METRICS_API_KEY (distinct from the server key — a leaked scrape token must not unlock the license envelope).

Why route through DVARA

Drop-in OpenAI compatibility means governance kicks in on call one — point any OpenAI SDK at DVARA and every request is:

• Policy-evaluated — YAML-defined policies run before the upstream call (see Routes & Policies)
• Audited — every request and response writes to the immutable, HMAC-signed audit trail
• PII-redacted — sensitive spans stripped or tokenized before leaving the perimeter
• Cost-attributed — per-tenant, per-model, per-API-key spend tracked for chargeback
• Routed — multi-provider failover, latency-aware routing, cost-aware routing
• Cached — semantic cache for repeated queries

All of this is transparent to your SDK code. You change one line.