Skip to main content
​
Session metadata

​
Send what you already know about a person

POST /v3/initialize now takes metadata: your own fields about the person the session is for — their plan, when they signed up, an internal department code, whatever your records hold. The fields are kept against that person and show up on their profile in the dashboard, beside the columns that arrive on an uploaded list, and the dashboard’s filters can match on any key you send.
  • Send it with an identifier — email, phone or external_id. A session with no identifier has nobody to attach the fields to, and is refused.
  • It never changes a result. Nothing the person walks through reads it, and a check settles exactly as it would without it.
  • Up to 50 keys per session. Keys 1 to 64 characters, string values 1 to 1024, and a value can be a string, a number or a boolean. An empty value is refused rather than dropped, so a session that comes back OK kept every key you sent.
  • Secret key only, like the other fields that name a person.
Nothing to upgrade. It works with the SDK version you already run.
​
Skip window

​
A new external_id is a new check

If you pass a fresh external_id on every session and rely on group to keep entries unique, a person coming back inside the skip window could be handed the earlier entry’s result: the same confirmation, the earlier external_id, and no duplicate reported. A session that carries a different external_id than the person’s last pass now runs its own check and settles its own confirmation, so a repeat in the same group is reported the way your collision setting says.
  • The same external_id coming back still skips, and so does a session with no external_id. The skip window itself is unchanged.
  • Nothing to upgrade. It works with the SDK version you already run.
​
Auto-return

​
Return the moment a check settles

POST /v3/initialize now takes auto_return. Set it and an approved check sends the person straight back to redirect_url the instant it settles, with no result screen and nothing to tap. Leave it off and they see the result screen and tap to return, as before.
  • Works with any key. It sets the behavior for that one run, whatever the verification has saved.
  • In an embedded flow the result arrives the same way, through the vycheck() promise and onComplete, and the drawer closes on its own.
  • A denied check still shows its result so the person sees why. Invite links ignore the field.
Nothing to upgrade. It works with the SDK version you already run.
​
Usage caps

​
A new denial reason: usage_cap_exceeded

Every account has a default daily limit on verifications (66k). A run that lands after the day’s limit has been reached now comes back denied with reasons: ["usage_cap_exceeded"] instead of reaching the verification step.
  • The limit resets daily at 00:00 UTC. Don’t retry a capped run in a loop; it fails the same way until then.
  • If you need your daily verification limit adjusted due to a launch, campaign or general traffic, contact us so we can adjust your limits.
Nothing to upgrade. This works with the SDK version you already run.
​
Groups

​
One group can now see another

Groups scope uniqueness to a pool, and until now every pool was sealed off from the others. POST /v3/initialize now takes include_groups: other groups whose history also counts against the run. To keep everyone who already passed spring-intake out of a follow-up, mint the follow-up’s sessions with their own group plus include_groups: ["spring-intake"].
  • A hit in an included group behaves exactly like one in the run’s own pool: it denies the person or flags the pass, following the verification’s settings.
  • The confirmation now carries groups, the pools the reasons came from, on flagged passes too. It reads [] when there is nothing to report.
  • The run still settles into its own group. An included pool is read, never written.
Nothing to upgrade. Both fields work with the SDK version you already run, and runs that pass neither field are unchanged.
​
Embedded flow

​
Reliability fixes 21:30 UTC

  • An older phone scanning the desktop QR code could be told the code was already used on another device. It now resumes where it left off. A different phone opening a used code is still refused.
  • The consent step could do nothing at all for a person whose session had died. It now refreshes and asks for one more tap.
  • Embedded flows now complete inside a native app webview.
Nothing to upgrade. All three work with the SDK version you already run.

​
No redirect URL needed for embedded flows 16:57 UTC

Open a verification with vycheck({ session, mode: "iframe" }) and you no longer have to pass a redirect_url to POST /v3/initialize. The embedded flow never leaves your page: when the person finishes, the result arrives through the vycheck() promise and your onComplete callback, and you confirm the token on your server as before.
  • Applies to the drawer and to display: "inline".
  • A redirect_url you do pass still wins, and still comes back with ?vyt=…&vyc=… appended. If you were only passing one to keep an embed working, you can drop it.
  • Nothing to upgrade. It works with the SDK version you already run.
Redirect mode is unchanged. It navigates away, so it still needs somewhere to send the person back to.
​
SDK 0.4.0

​
Embed a server-minted session

vycheck({ session }) runs a session you created on your server, so an embedded flow can carry an external_id or a bound identity that only a secret key can set.
  • Call POST /v3/initialize from your backend with external_id, email, or phone. It now returns a session_id next to url.
  • Pass the session_id to vycheck({ session }) in the browser. The flow opens as a drawer or inline, with no redirect.
  • Confirm the returned token on your backend as before.
Embedded flows previously ran from the publishable key alone and couldn’t attach an external_id. Now they can.

​
close() on the vycheck handle

vycheck() returns a handle with a close() method to dismiss a drawer or inline embed before the person finishes. See vycheck().

​
Documented confirmation reasons

The reasons on a confirmation are now enumerated in the API reference, each with a line on what it means: collision_company, identity_mismatch, duplicate_account, and the rest.
​
SDK 0.2.0

​
SDK 0.2.0 is the new default

npm install @verifyyou-sdk/client now installs 0.2.0. The headline: you choose how the flow appears.
  • Display modes. Alongside the classic redirect, the flow can now open as a drawer that slides over your page or inline inside an element you own. Pick the mode once in init(); vycheck() stays the same call.
  • Completion callbacks. In the embedded modes the result is delivered to your onComplete callback and resolves the vycheck() promise. No redirect, no lost page state.
  • Production by default. SDK builds now target the production API out of the box.
If you’re on 0.1.1, the core contract is unchanged: the same vyt/vyc return parameters and the same backend confirmation. See the updated vycheck() and vyget() pages for the new result shape.

​
Richer confirmation responses

GET /v3/confirmations/{token} now returns more than the verdict:
  • status: approved or denied (approved with findings is presented as flagged)
  • reasons: the rule findings behind the status, such as collision_company
  • confirmed_at: when the verdict settled
  • identity: the verified email or phone, when your verification has sharing enabled
  • id: the confirmation id
verified remains the field to gate on.

​
Key check endpoint

POST /v3/keys/test validates any key and reports its type and mode. Wire it into setup scripts or healthchecks.

​
Docs

  • New init() page covering setup and the display modes
  • Identity and recognition: clearer story on device IDs and the claim a verified identity gives a person over their own uniqueness
  • Condensed uniqueness explanation: check group (company or network) and collision action (block or flag)
  • Flow tracking webhooks and the Platform API pages were removed ahead of deprecation