Skip to content

Integrating an application

For the engineer pointing an existing application at Tavrik. The short version: you change a base URL and a key, and nothing else.

How a request is handled Every request passes through the same chain: validated, patient details replaced with placeholders, policy applied, routed to a model, the answer returned, details restored, and an audit event written. Prompts and answers are not stored; what is recorded is that a request happened, what kinds of details were found, and whether it was allowed. How a request is handled Tavrik Pty Ltd, trading as Tavrik AI © 2026 Tavrik Pty Ltd, trading as Tavrik AI. All rights reserved. INBOUND OUTBOUND Validate Well-formed request from a known key 01 Tokenise Patient details become placeholders 02 Policy Your rules applied: allow or block 03 Route Sent to the model set for this tenant 04 Restore Real details put back into the answer 05 Audit Event written to the tamper-evident chain 06 local or cloud model WHAT THE CLINICIAN TYPED Mrs Eleanor Whitfield, MRN 4471902, DOB 12/03/1948 WHAT THE MODEL RECEIVED {NAME_1}, MRN {MRN_1}, DOB {DOB_1} WHAT THE CLINICIAN SEES Mrs Eleanor Whitfield, MRN 4471902 Prompts and answers are not stored. What is recorded: that a request happened, which kinds of details were found, and the decision.

The endpoints

Section titled “The endpoints”

Tavrik speaks two request shapes, so most applications need no new client library.

Endpoint Shape
POST /v1/messages The Anthropic Messages API
POST /v1/chat/completions The OpenAI chat-completions API
GET /v1/models The models this deployment allows

Point your existing SDK at your Tavrik deployment’s base URL and give it a Tavrik tenant API key instead of a provider key. Streaming works as it does against the provider.

Your provider keys stay in Tavrik, uploaded once and stored as ciphertext. The application never holds one, which is a side benefit worth having: a leaked application credential is a Tavrik key you can revoke in the console, not a provider key with your whole account behind it.

What happens to a request

Section titled “What happens to a request”

Every request takes the same path, and the diagram above is the long version:

  1. Authenticated against a tenant API key.
  2. Inspected: patient details and other configured categories are found and replaced with placeholders before anything leaves your network.
  3. Policy is applied: allow, redact, or deny, according to the rules your deployment has active.
  4. Routed to the model you allow, which may be a local one, in which case nothing leaves the building.
  5. Restored on the way back, so your application sees the real values.
  6. Recorded in the audit chain: that a request happened, which categories were found and how many, and what was decided.

Your application sees a normal model response. The substitution and restoration happen inside Tavrik.

What this means for your code

Section titled “What this means for your code”

Nothing changes in how you build prompts or read responses. What changes:

  • The base URL points at Tavrik.
  • The API key is a Tavrik tenant key.
  • A request may be denied by policy. That surfaces as an error with a reason your application should handle the way it already handles a provider refusal.

Where the boundary sits

Section titled “Where the boundary sits”

Tavrik is a governance layer for AI traffic. It sits alongside your integration engine and your data-loss-prevention tooling rather than replacing either.

Clinical message flow between your EHR and your lab or pharmacy systems keeps running exactly as it does now. Tavrik does not mediate clinical FHIR APIs either: the FHIR path emits audit records only. Mirth Connect, Cloverleaf and Rhapsody stay where they are, and Tavrik sends audit messages to them like any other feed.