Trust Reuse

Trust Reuse lets a returning user who already verified at another Stile operator — and explicitly consented to share — pass verification at your application instantly: no camera, no ID upload. This page covers how to enable it, how reused sessions show up in your existing integration, the webhook events involved, and the privacy model behind it.

What it is

When a user verifies with Stile at one operator, they can opt in to share that verification with other operators on the platform. If that user later shows up at your application, the shared credential satisfies your verification session in place of a fresh verification flow.

This is opt-in on both sides:

• The user explicitly consents on the success screen of their first verification ("Save my verification for use at other Stile operators")
• The operator explicitly opts in in their Trust Reuse settings to accept reused verifications

If either side hasn't opted in, the user goes through the normal verification flow at your application — exactly as they would today.

Why use it

• Lower abandonment — returning users skip a 60–120 second camera + ID flow
• Same trust level — you only accept verifications that match your method, jurisdiction, and recency policy
• You're not on the hook for someone else's bad data — you set the acceptance bar (max age, allowed methods, jurisdiction lock); credentials that don't meet your bar fall through to fresh verification automatically
• Full audit trail — every accepted grant has its source operator, source credential, method, and timestamps recorded against your org

Enabling Trust Reuse for your application

In the dashboard, go to Settings → Trust Reuse. You'll see:

How it shows up in your flow

You don't need to change any code to participate. After enabling Trust Reuse:

1. Your existing POST /v1/verification_sessions calls work exactly the same — same request, same response shape
2. When the user happens to qualify for reuse, the session is created with status: "verified" immediately, instead of status: "created" (which would normally wait for the camera flow)
3. The standard verification_session.verified webhook fires
4. Optionally, you also receive a trust_reuse_grant.created webhook — see below

Webhook events

Subscribe to these in Settings → Webhooks to receive structured signals about Trust Reuse activity affecting your application. They're delivered through your standard webhook endpoints and signed like every other event — verify them the same way (see Webhook verification).

trust_reuse_grant.created

Fires when a reuse grant is created for your application. The data.object contains:

{
  "object": "trust_reuse_grant",
  "id": "trg_...",
  "source_org_id": "org_...",
  "target_org_id": "org_yours",
  "session_id": "vks_...",
  "verified_person_id": "vp_...",
  "method": "DOCUMENT_CAPTURE",
  "age_tier": "MIN_AGE_21",
  "strength": "DOCUMENT_CAPTURE",
  "granted_at": "2026-05-12T10:00:00Z",
  "expires_at": "2027-05-12T10:00:00Z",
  "revoked_at": null,
  "revoked_reason": null
}

You'd typically log this for compliance audit and treat it as equivalent to a fresh verification_session.verified event.

trust_reuse_grant.revoked

Fires when an accepted grant is revoked. Common reasons:

• USER_REVOKED — the user clicked the revoke link in our notification email
• USER_REVOKED_CONSENT — the user pulled all sharing across all operators, which includes your grant
• ERASURE_REQUEST — the user was erased from the platform; their verification is gone everywhere
• TARGET_OPERATOR_REVOKED — you yourself revoked this grant via the dashboard or API
• SOURCE_CREDENTIAL_REVOKED — the source operator removed the underlying credential

You should treat the user as no-longer-verified for future actions. Past sessions are not retroactively invalidated.

trust_reuse_consent.revoked_by_user

Fires when the user revokes their sharing consent platform-wide. Sent to every operator currently holding a derived grant. If your downstream system caches "this user is verified," this is your cue to clear it.

Revoking access from your side

In Settings → Trust Reuse → Accepted grants, you can revoke any individual grant. Revoking does:

• Marks the grant as revoked in our ledger
• Fires trust_reuse_grant.revoked to your webhook endpoint (closes the loop with your downstream systems)
• Does not invalidate any verification sessions already marked verified — those are historical facts; future reuse with this person won't fire

What the user sees

After a successful first verification (at any Stile operator), the user sees a single optional checkbox on the success screen:

Save my verification so other operators don't have to re-verify me.

Default is unchecked — they have to actively opt in.

If they do opt in, every time a future operator accepts a reuse grant from their consent, the user gets a transactional email from us:

Acme Carrier just used your existing Stile verification. If you didn't expect this, click here to revoke their access.

The link in the email is a one-shot signed URL — one click revokes the specific grant, with no login, no password, no account page. They can also "revoke all sharing" from the same email to pull consent platform-wide.

Operator-to-operator privacy

Trust Reuse is designed so that you can never learn anything about which other operators a user has been verified with unless the user explicitly tells you (by getting reused at your application). Specifically:

• You cannot enumerate which users have been verified elsewhere
• A failed reuse attempt (any decline reason) is internally indistinguishable from a user who has never been on the platform — both fall through to fresh verification with identical observable behavior
• The cross-operator anchor table (verified_persons) is accessible only via narrow SECURITY DEFINER functions that return existence booleans, not row metadata

Frequently asked questions

Next steps