Skip to main content
We handle bots, dupes, and fraud before they get to you. All you decide is where to put the human check in your flow and what happens when someone passes.
These endpoints are public and heavily rate limited. Grab an API key to remove the limits.
1

Create a verification

Step 1: Create a verification

Call POST /v2/verification/create from your backend with a return URL. You get back a link; send your user there.
Response
You can add external_ids to help keep track of accounts. See External IDs for details.
Redirect the user to verification_url: open it as a redirect, in a modal webview, or a new tab.

Skip phone verification with phone

If you’ve already verified the user’s phone number on your end (e.g. your own SMS login, an authenticated session), pass it in phone. The returned verification_url will land the user directly on the liveness check, with no phone-OTP step. Same field, same code path on your side; only the URL shape changes.
Request
Response
The verification_url is the trust anchor; anyone with it can complete the flow as that user. Deliver it over a channel you’ve already authenticated (post-login redirect, authenticated email, push notification). Don’t drop it in a public page or unauthenticated email.
phone skips the OTP step, not the verification itself; every call runs the full liveness check.
2

We verify them

Step 2: We verify them

Once the user lands on our flow, VerifyYou runs a two-stage check automatically:
  1. Phone number check: a verified phone number acts as a persistent identifier that follows the user across devices, browsers, and sessions.
  2. Liveness + uniqueness scan: confirms a real human is present and they haven’t verified under a different account.
Desktop vs. mobile. If your user hits the flow on desktop, we hand them off to their phone via a QR code: they scan, complete the liveness capture on mobile, and (on success) the desktop session automatically advances and redirects back to your redirect URL. Users who start on mobile stay on mobile and complete the whole flow on one device. Either way, your app just gets one redirect back with the same query params; you don’t need to branch your integration on device type.
A denied result isn’t a single thing; it means the user failed one of a few checks:
  • Liveness: the capture didn’t confirm a real person was present (e.g. photo of a photo, screen replay, mask).
  • Uniqueness: the person has already verified under another account, either in your app or elsewhere on our network.
  • Risk signals: patterns consistent with fraudulent attempts.
We don’t return the specific reason per attempt on purpose. Exposing which check failed would give bad actors a map of what to try next. That said, we’re working on getting this data back to you in a shape that’s actually useful; more on that down the road.
When done, we redirect back to your redirect URL with query params appended:
Want to try the flow right now? Generate a test phone number with the sandbox; no API key needed:
Running the flow yourself? There are a few quirks worth knowing: test phone numbers, account stickiness across browsers, and human review. See Testing the flow before you start.
3

Confirm the result

Step 3: Confirm the result

Never trust the vy_status query param alone; anyone can fake a URL. Call POST /v2/verification/status from your backend to confirm.
Safe to poll: an in-flight verification (created but the user hasn’t finished yet) returns 200 with verification_complete: false. A 404 only happens for tokens or external_ids that don’t match any verification.
Option A, check by token:
Option B, check by external ID:Use this when the token has expired (after 15 minutes), or when you want to check status without a redirect flow.
Response
Status answers at the user level, not the session level. Looking up by external_id returns true as soon as any session for that user has completed. Useful if you call verification/create more than once for the same user (e.g. to deliver the URL via different channels). See Reusing the same external_id for details. Looking up by token is always session-scoped.
That’s it. Two endpoints, one redirect, one check. Your user is verified as a real, unique human.

API Reference

Full endpoint docs with interactive playground