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 “Generate/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 Advanced 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. If you haven't generated an API key yet, do that first, using the “Generate/Rotate API Key” button covered in step 1. Once you have a key, scroll down to the “Integration Snippet” card, where you'll find the same code shown below, ready to copy directly into your own backend.
// Reuse the SAME request_id if you retry this exact event after a
// failure. Only generate a NEW request_id for a genuinely new event,
// this is what guarantees idempotency and prevents duplicate logs.
//
// Placeholders to replace with your own values:
// - chatLog.text -> wherever your code stores the conversation text
// - errorTrace -> wherever your code captures error details
// - elapsedMs -> however long your AI call actually took, in ms
// - model: 'gpt-4o' -> accepts any string (claude-sonnet-5, gemini-2.5, etc.)
// - duration_ms: 1250 -> an example number, use your elapsed time
// ============================================
// Use this block where your AI responds successfully
// ============================================
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) => {
// If this specific request fails, don't just lose it. This next
// line calls a function named saveLocallyForRetry, but that
// function does NOT exist yet, you need to build it yourself.
// Most people build this to run automatically, checking periodically
// for saved, failed logs and resending them on its own, but it's
// your choice, you could also just save them somewhere
// and resend manually if you'd rather.
saveLocallyForRetry(chatLog, err);
});
// ============================================
// Use this SEPARATE block where your AI call fails.
// This does not go after the block above, it goes in
// a completely different part of your code, your error handling.
// Recording both outcomes, success and failure, fits how compliance
// frameworks like Article 12 are generally understood, full
// traceability of what actually happened. 'model' is flexible here
// too, same as above.
// ============================================
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: errorTrace,
event_type: 'system_error',
metadata: { model: 'gpt-4o', duration_ms: elapsedMs },
}),
});What each part of this code does:
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.