Dashboard overview

The Drukverify Dashboard at dashboard.drukverify.com is the logged-in self-serve UI your team uses to manage their integration: minting API keys, watching real-time usage, inspecting audit traffic, wiring webhook endpoints, and inviting collaborators. It complements the SDKs (which sit in your app code) and the public docs at drukverify.com (which describe the API surface).

Who it's for

Every tenant has at least one user on the dashboard — the person who set the account up. From there, admins invite teammates and assign roles. Three role tiers cover the common cases:

Role	Reads	Writes	Typical user
admin	everything	everything (manage keys in both modes, manage team, manage webhooks, edit settings)	The person owning the integration end-to-end. Usually one or two per tenant.
developer	everything	test-mode keys, audit log, usage — but not live keys, team, or webhooks	Engineers building against the API who shouldn't be able to mint production credentials.
viewer	audit log, usage, settings	nothing	Compliance, ops, or finance roles who need to see traffic and billing but not change anything.

Role gates are enforced at the API layer too — the UI mirrors them so disabled buttons explain why an action isn't available, rather than letting a click result in a 403 toast.

What the dashboard covers

• API keys — create, name, revoke, and audit your sk_ / pk_ keys in both live and test mode.
• Team — invite users, change roles, see who's been logging in.
• Usage — daily call counts and billable-unit totals by feature, variant, or status, with a 7 / 30 / 90 day window and a live ⇄ test toggle.
• Audit log — every API request your keys and session tokens have made, with status, latency, and request_id for support.
• Webhooks — register endpoints to receive ocr.completed, face.verify.completed, and liveness.check.completed events. One-time signing-secret display on creation.
• Settings — read-only tenant metadata for now (name, slug, plan). Plan and billing changes go through ops.

What it does NOT cover

Some flows are deliberately not in the dashboard:

• Provisioning a new tenant. New tenants are created out-of-band today — contact ops to onboard. Once a tenant exists, the setup flow handles initial-admin enrollment via emailed setup link.
• Plan / billing changes. Email ops@drukverify.com. A self-serve billing surface is a future iteration.
• Live in-product API testing. Use the API reference on this site (interactive try-it panel), or run requests against https://api.drukverify.com directly with your sk_ key.

Security model

• Sessions use a short-lived signed cookie (dv_dash) issued after email + password + TOTP. Backup codes available for TOTP-loss scenarios.
• TOTP is required for every role, no exceptions. Backup codes (8, single-use) are generated at enrollment.
• All /admin/* mutations are persisted as audit events under your tenant's audit log — including the dashboard user that performed them, the request IP (masked), and the timestamp.