The full Trustable flow, end to end
Follow these six steps to demo both sides of the marketplace: an individual who verifies once, and a business that gets cryptographic proof without ever seeing personal data.
- Step 1. Get verified as an individualSign up as an Individual, then complete the simulated verification wizard — document, selfie, and liveness checks are all mocked. You end up with a reusable credential and minimal verified claims.
Talking point: The user verifies once. No documents are stored — only derived claims like "over 18".
Sign up as individual - Step 2. Set up a business (second browser or incognito)Sign up as a Business developer, register an application with the claims it needs, and create an API key. This is the developer side of Trustable.
Talking point: Businesses integrate in three API calls and never touch raw identity data.
Sign up as business - Step 3. Create a verification requestFrom the dashboard Requests tab, create a request choosing the claims and purpose. Copy the generated consent link — in production this comes from the REST API.
Talking point: The request specifies exactly which claims are needed and why. Data minimization by design.
Open dashboard - Step 4. Approve as the userOpen the consent link while signed in as the individual. The consent screen shows what will be shared and, just as importantly, what will never be shared. Approve to receive a signed proof token that expires in 5 minutes.
Talking point: The user is always in control. The token subject is a pairwise pseudonym, so apps cannot correlate users.
Open portal - Step 5. Inspect and verify the tokenPaste the token into the public token inspector to see its contents — verified claims only, no PII. Businesses verify it server-side via POST /api/v1/tokens/verify.
Talking point: Cryptographic proof, minimal claims, short expiry. This is the whole product in one JSON payload.
Open token inspector - Step 6. Revoke and watch it failBack in the portal, revoke the credential. Re-verify the same token in the inspector — it is now rejected because the underlying credential was revoked. Webhook deliveries and the audit log record everything.
Talking point: Users can pull consent at any time, and businesses find out immediately.
Revoke in portal