A complete walkthrough of your dashboard, what every button does, and how to verify a log, step by step.
Once your conversation data reaches Vanzim, we permanently remove specific sensitive details from it, before anything is stored anywhere. Here's everything that gets caught, on every plan:
On the Pro plan specifically, two more categories are also caught:
Each one gets replaced with a tag, [REDACTED_EMAIL], [REDACTED_PHONE], [REDACTED_CARD], [REDACTED_AGE], [REDACTED_DATE]. This is permanent and irreversible, once replaced, the original value is gone from anything Vanzim ever writes anywhere.
Here's what this doesn't catch: names, physical addresses, insurance IDs, and any other identifier not on this exact list are not currently detected. Don't treat this as a complete, catch-all redaction system on its own.
Want us to catch something that isn't on this list yet? Email contact@vanzim.com and tell us what you need. If it genuinely helps our users, we'll build it.
If you might need the full, original, unredacted conversation later, for your own records, a support ticket, or any other reason, you must keep your own separate copy in your existing systems, your CRM, your support platform, wherever that conversation naturally lives on your side. Vanzim proves your scrubbed record hasn't changed since it was created, it is not meant to be your only copy of anything.
Go to Configuration. Find the card titled “Rotate API Key.”
If you ever need to rotate your key again later (for example, if you suspect it's been exposed), the exact same button and process applies. Rotating instantly breaks any system still using the old key. This means you must also update the actual key value wherever your own backend uses it, usually stored as an environment variable, like VANZIM_API_KEY, on your own server, not just here in the Vanzim dashboard. Rotating here alone doesn't update your backend automatically, that's a separate step you have to do yourself, right after rotating. If you also change any settings on the AWS side yourself, like rotating your AWS access keys, you need to come back here and update those in Configuration too, otherwise Vanzim will start failing to reach your bucket.
Still on the Configuration page, find the “AWS Configuration” card.
Fill in:
Two more things are required before you can save at all:
Once both are filled in, click “Save AWS Credentials.” The moment you save, Vanzim independently checks your bucket directly with AWS, not just trusting the checkbox. You'll see one of two results right there: “AWS confirms: Object Lock enabled” (with the actual mode and retention period shown), or “AWS confirms: Object Lock is not currently enabled.” This isn't a separate step, it happens automatically the moment you save.
Still on Configuration, find the “PII Scrubbing” card.
If you're on the Starter plan, this toggle is disabled, with a message pointing you to upgrade if you want Strict mode.
If you're on Pro, toggling this either direction shows you a confirmation dialog first, explaining exactly what's about to change. This only ever affects new logs sent after you make the change, it never goes back and reprocesses anything already archived.
Go to Configuration, scroll to the “Integration Snippet” card. This only appears once you've generated your API key, since the code shown there is personalized with your real endpoint. It has its own “Copy” button, you don't write this from scratch, you copy it directly and paste it into your own backend.
Your dashboard actually shows you two different, complete versions of this code, side by side, and you choose which one to use.
Option one: “With Fail-Open (Recommended)”
try {
await fetch('https://vanzim-worker.vanzim.workers.dev/v1/ingest', {
method: 'POST',
headers: {
'Authorization': `Bearer ${process.env.VANZIM_API_KEY}`,
'Content-Type': 'application/json',
},
body: JSON.stringify({
request_id: crypto.randomUUID(),
raw_text: chatLog.text,
event_type: 'chat_completed',
metadata: {
model: 'gpt-4o',
duration_ms: 1250,
},
}),
});
} catch (err) {
saveLocallyForRetry(chatLog, err);
}Option two: “Simple (No Fail-Open)”
await fetch('https://vanzim-worker.vanzim.workers.dev/v1/ingest', {
method: 'POST',
headers: {
'Authorization': `Bearer ${process.env.VANZIM_API_KEY}`,
'Content-Type': 'application/json',
},
body: JSON.stringify({
request_id: crypto.randomUUID(),
raw_text: chatLog.text,
event_type: 'chat_completed',
metadata: {
model: 'gpt-4o',
duration_ms: 1250,
},
}),
});These are genuinely different, not the same code shown two ways. The second version has no error handling at all. If Vanzim is ever briefly unreachable and you're using this simpler version, that specific request just fails silently, with nothing saved and nothing retried.
What each part means, applies to both versions equally:
VANZIM_API_KEY.If you pick the first, recommended option, you need to actually write and implement saveLocallyForRetry() yourself, matching however you store data (a local queue, a file, a row in your own database). It's shown as a comment, but nothing happens automatically, you have to implement it. If you pick the simpler, second option, understand clearly that you're accepting the tradeoff, no automatic recovery if Vanzim is briefly unreachable.
Go to your dashboard's main Ledger view. Every log you've sent appears here, in a table with six columns:
This is the fastest way to check a specific log yourself.
This tool already knows the correct, original hash for the specific log row you clicked “Verify” on, and directly compares your freshly computed hash against it. If you accidentally drop a file from a different log, you won't see a specific “wrong file” warning, you'll simply see a Hash Mismatch, since a different file naturally produces a different hash.
You'll see one of two outcomes. Hash Verified means the file is authentic and hasn't been altered since creation. Hash Mismatch means something about the file has changed since it was first sealed.
Either way, two hash values are shown together for you to compare yourself: the one your browser just computed from the file you dropped in, and the original one Vanzim recorded when this log was first created, retrieved from your dashboard's Ledger.
This is the same underlying check, but doesn't require logging in at all, useful when someone outside your own team, a customer's lawyer, an auditor, a regulator, needs to check a file themselves without needing to trust your word, or Vanzim's.
Right now, both verification methods only handle one file at a time. If you need to check many logs, you'll need to verify them individually, one at a time, for now. Bulk verification is something we're actively working on, but it isn't available yet.
If anything here doesn't match what you're seeing, or you run into an issue not covered, reach out at contact@vanzim.com.