Introduction to Verification
Blerify Verification lets your backend confirm that a person's digital credential is valid, unrevoked, and held by the person presenting it — without you handling any cryptographic logic.
You configure what to verify once in the Portal. At runtime, your backend calls two endpoints: one to start a session, one to retrieve the result. Everything in between — credential validation, trust chain checks, biometric evidence collection — runs inside Blerify.
Choose your integration pattern
Pick the path that fits how your app is built — this determines which guide to read next.
Web app. You have two options, depending on how much UI you want to own:
You build your own verification UI — your backend calls the Blerify API directly, your frontend shows the prompt, you poll for the result. Start with Verify from a Web App.
You want Blerify to host the verification page — your backend redirects the user to a Blerify-hosted page, Blerify handles the entire wallet interaction, and redirects back to you with the result. Use this if you don't want to build any credential-specific UI at all. Start with OAuth Verification Flow.
Native mobile app (iOS or Android). Your app opens the Blerify Wallet directly via a deep link instead of showing a QR code. You still call the same backend API as the web direct-integration path — the difference is entirely in how your frontend triggers the wallet and receives control back. Start with Get Started for the backend calls, then Mobile Integration for the deep-link mechanics on each platform.
Not sure yet? Get Started is the fastest way to see a verification work end to end before committing to a pattern — everything in it still applies if you add the OAuth flow or move to native later.
What Blerify validates
For every credential presented, Blerify checks:
Signature — the issuer's cryptographic signature is intact and matches the credential data
Issuer trust — the issuer appears in the trust list configured in your verification template
Revocation — the issuer has not revoked this credential
Expiry — the credential's validity period has not passed
Holder binding — the presentation is cryptographically bound to the current session; replays are rejected
These checks run on every verification regardless of assurance tier. Beyond them, you can require additional evidence — hardware key attestation, device integrity, facial liveness — by setting an assurance tier on your template. See Assurance Tiers for the full model.
What's in this section
Your first working verification: authenticate, start a session, present it to the user, poll for the result.
Build your own verification UI in a web app — authenticate, start a session, present it to the user, poll for the result.
The full session lifecycle, the complete result schema per tier, evidence interpretation, and every error case.
The redirect-based pattern — Blerify hosts the verification UI.
Native iOS and Android deep-link mechanics for triggering the wallet from your own app.
What Basic, Standard, and Premium each prove, and how to choose.
How the credential's signing key is bound to the user's biometrics, and what that means for non-repudiation.
The Android/iOS attestation asymmetry — why some evidence fields are absent on iOS.
Who can create and manage verification templates in the Portal.
The dry endpoint contract — request and response schemas, error codes, session states.
Next steps
Get Started with Verification — your first working integration in five steps
Authentication — create the service account you'll need for any integration pattern
Last updated