Documentation

Drop Sluis in front of your model calls.

Sluis is an OpenAI-compatible proxy. Change one line, your base_url, and every request starts flowing through your residency policy and into the tamper-evident ledger. No SDK to learn, no payloads to rewrite. Five steps below; the full reference lives in the sidebar.

Time to first sealed call: ~2 minutes. If your code already talks to OpenAI, you keep your client, your models, and your message format exactly as they are.

Get a key

Create a key in the Console under API keys. Each key carries a residency policy and a budget, so you can scope eu-only for production and eu-uk-us for a research sandbox without changing any code.

# keep it in your environment, never in source
export SLUIS_KEY="sk_live_a91c…"

Point base_url at Sluis

Swap the host. Everything downstream (models, streaming, tools, function calling) works unchanged because Sluis proxies the same API surface.

from openai import OpenAI

client = OpenAI(
    base_url="https://api.sluis.ai/v1",
    api_key=os.environ["SLUIS_KEY"],
)

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://api.sluis.ai/v1",
  apiKey: process.env.SLUIS_KEY,
});

// no SDK required — reqwest = { version = "0.12", features = ["json"] }
let client = reqwest::Client::new();
let base = "https://api.sluis.ai/v1";  // ← the only change
let key  = std::env::var("SLUIS_KEY")?;

curl https://api.sluis.ai/v1/chat/completions \
  -H "Authorization: Bearer $SLUIS_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "model": "mistral/mistral-large-latest", "messages": [...] }'

Send a request

Call it exactly as you would call the provider. Sluis inspects the request, routes it through your policy, and returns the model's response with two extra headers that tell you where it ran and how it was sealed.

# Anthropic Claude, served from Google's EU multi-region
resp = client.chat.completions.create(
    model="vertex/claude-opus-4-8",
    messages=[{"role": "user", "content": "Summarise this chart…"}],
)
print(resp.choices[0].message.content)

// Anthropic Claude, served from Google's EU multi-region
const resp = await client.chat.completions.create({
  model: "vertex/claude-opus-4-8",
  messages: [{ role: "user", content: "Summarise this chart…" }],
});
console.log(resp.choices[0].message.content);

// Anthropic Claude, served from Google's EU multi-region
let resp: serde_json::Value = client
    .post(format!("{base}/chat/completions"))
    .bearer_auth(&key)
    .json(&serde_json::json!({
        "model": "vertex/claude-opus-4-8",
        "messages": [{ "role": "user", "content": "Summarise this chart…" }]
    }))
    .send().await?
    .json().await?;

println!("{}", resp["choices"][0]["message"]["content"]);

200 OK · sealed in 3ms

{
  "x-sluis-region": "eu multi-region",
  "x-sluis-provider": "vertex · claude-opus-4-8",
  "x-sluis-decision": "in-region",
  "x-sluis-seal": "#4f9c2a",
  "x-sluis-prev": "#e1b7d9"
}

Set residency per request

The key's policy is the default. Override it for a single call with a header, useful when one endpoint handles a stricter data class than the rest of the key.

resp = client.chat.completions.create(
    model="mistral/mistral-large-latest",
    messages=msgs,
    extra_headers={"X-Sluis-Residency": "eu-only"},
)
# PHI in the prompt? Sluis routes EU-only and
# blocks with 451 if no EU provider is available.

const resp = await client.chat.completions.create(
  { model: "mistral/mistral-large-latest", messages },
  { headers: { "X-Sluis-Residency": "eu-only" } },
);
// PHI in the prompt? Sluis routes EU-only and
// blocks with 451 if no EU provider is available.

let resp = client
    .post(format!("{base}/chat/completions"))
    .bearer_auth(&key)
    .header("X-Sluis-Residency", "eu-only")
    .json(&body)
    .send().await?;
// PHI in the prompt? Sluis routes EU-only and
// blocks with 451 if no EU provider is available.

The header can only make a request stricter than the key's policy, never looser. A request can never widen its own residency. To broaden where data may go (say, to allow US or Chinese providers) change the base policy in the Console.

Need to keep personal data out of the model entirely, so you can use any model without leaking a single name, number, or secret? Enable Policies → Data protection: Sluis replaces detected PII and secrets with stable typed tokens (e.g. «EMAIL_1»), forwards only the tokens to the provider, and restores the originals in the response. The map is never persisted. That is what makes a US or Chinese model safe to call. The full detector library and name detection are covered in the Data protection reference below.

Verify the seal

Every call appends an entry to the hash chain. Pull the chain and re-verify it offline, each entry's hash is sha256(prev_hash + record), so any altered field downstream breaks every link after it.

curl https://api.sluis.ai/v1/audit/export?from=genesis \
  -H "Authorization: Bearer $SLUIS_KEY" | sluis verify -

# → 18,442 entries · chain intact · head #4f9c2a ✓

Open the Console →

Create keys, edit residency policy, and watch the audit chain fill in real time.

How sealing works →

The mechanics of the hash-chained, tamper-evident ledger.

API reference →