What we actually do with your data

When you verify your identity in Settings, the actual government-ID check happens entirely on Stripe’s side. Emerpa never sees your ID document or the biometric match — Stripe tells us only whether verification passed, failed, or needs more input.

Role changes, membership removals, credential verifications, and every other logged compliance action are written once and never edited afterward — including by us. There is no update path on this table at all, at the database level. If your organization is ever asked to produce a record of who did what and when, this is designed to be something you can actually rely on.

Two things do change these records, and we would rather name them than let you find out later. When someone deletes their account, their name comes off the entries they made — the entry itself survives, showing what happened and when, but no longer who. And when an organization is closed entirely, its log goes with it. Both are deliberate: a person who leaves is entitled to stop being named, and a log kept for an organization that no longer exists is a record with nobody left to answer to.

What that means in practice: this log is reliable for as long as your organization is, which is the window it was built for. It is not an archive we keep about you after you have gone.

Where a credential type has a real public registry (state nursing boards via Nursys, ServSafe, NMLS, CPAverify, DocInfo, NIPR, and others), Emerpa links directly to that registry’s own official lookup page and records when a person confirmed their credential matches it. This is a manual confirmation against the primary source, not an automated database cross-reference — we say so in the product, not just here, because the distinction matters.

For credential types with no single national registry (contractor and attorney licenses, for example, which are regulated per-state), Emerpa says that honestly rather than pointing you at a link that won’t actually have your record.

These are every third party Emerpa sends data to, what reaches them, and why. It is the list enterprise buyers ask for, so it is worth being exact rather than reassuring.

• Supabase

  Database, file storage, and authentication

  Your account, your credential records, and the document files themselves.

• Vercel

  Application hosting and page-view counts

  Request metadata in the ordinary course of serving pages, plus anonymous page-view counts that set no cookie and build no cross-site profile. Credential files are not stored here.

• Google Cloud (Vertex AI)

  Reading uploaded credentials

  The document you upload, for extraction only. See the first section on this page for how that runs.

• Stripe

  Payments and identity verification

  Billing details, and — if you verify your identity — your ID document, which Stripe holds and Emerpa never receives.

• Resend

  Transactional email

  Your email address and the contents of expiration reminders, invitations and notifications.

• Anthropic

  The “Ask Emerpa” assistant on the marketing site

  Only what you type into that chat box. It has no access to your vault, your credentials or your account.

A Data Processing Agreement is available on request. There is deliberately no download link here yet: a DPA is a contract rather than a web page, and publishing something that looks like one before it has been through counsel would be worse than saying plainly that it is not ready.

Emerpa sets one cookie, and only after you accept the banner: cw_theme, holding the name of your chosen theme for a year. Its entire job is letting the server send the right colours on the first paint, so the page doesn’t flash the default theme before your own loads. Decline and everything still works — the preference lives in your browser’s local storage and, if you’re signed in, on your profile.

There are no advertising cookies, no analytics cookies, and no third-party trackers, because there is no advertising or third-party analytics in this product to serve them.

A few other things are kept in your browser’s local storage rather than in cookies, which means they never travel with a request: cw_theme, cw_cookie_consent, cw_onboarding_dismissed, credwallet_active_org_id, and your Supabase session token, which is what keeps you signed in.

A small, separate table — distinct from any organization’s own manager/employee roles — controls who has platform-level administrative access. Every admin action (plan changes, account-level overrides) is written to its own permanent, append-only log, and the current list of who holds admin access is itself visible to other admins, not hidden.