VerifyHuman

In-app browsers & the camera

Many survey respondents open the survey inside an in-app browser: the browser built into Instagram, Facebook, TikTok, Telegram, LinkedIn, Gmail and similar apps. On Android especially, these browsers block the camera without telling anyone (they never pass on the phone's camera permission), so a camera check can't run. VerifyHuman handles this for you automatically. This page explains what happens and the two settings you can change.

What the SDK does automatically

When the check sees that the app blocked the camera (rather than the respondent saying no), it does not fail the respondent as “not human.” Instead it offers two ways forward:

  1. Finish on the phone with a QR code. The check shows a “Verify on your phone” panel: a QR code, a Copy link, and (on Android) an Open in browser button. The respondent finishes the check in their phone's normal browser, and the original tab continues automatically with a full camera result.
  2. Continue without camera. If they choose this (or the phone hand-off can't finish), the check finishes as a device-only check: a real result from the respondent's device and on-page behaviour. It is weaker than a camera check, but the respondent is never stuck.

This is on by default whenever our script runs the check for you (VH.mount(), the HTML snippet or the React component). There is nothing to set up.

Read the result: which level of check ran

Because a check can finish at different strengths, every result carries two fields so you always know what actually ran. They are on the SDK result, the signed vh_token, the /token/verify response and the webhook event:

{
  "status": "pass",
  "assuranceLevel": "biometric",        // biometric | device_only | none
  "verificationOutcome": "completed",   // completed | unverified_technical | declined_by_user
  "token": "eyJ…"
}
  • assuranceLevel — how strong the check was. biometric = a real camera check ran (on the page or through the QR code hand-off), confirming a live person who has not taken part before. device_only = no camera; device and on-page behaviour only. none = nothing could be checked.
  • verificationOutcome — why you landed there, so you can tell “wouldn't” from “couldn't.” completed = the check finished with a result. unverified_technical = the app or browser blocked the camera. declined_by_user = the respondent chose to continue without verifying.

Use these to handle respondents however your study needs: for example, accept everyone but send device_only to review, or accept biometric only.

Require a minimum level of check (optional)

By default, a device-only pass is accepted and clearly labelled, never blocked. A study that needs stronger proof can set the project's minimum level of check:

  • none (default) — accept any level; label the result, don't block it.
  • device_only — reject results where nothing could be checked at all (for example a capture that failed, or a respondent who declined) even if they would otherwise pass.
  • biometric — require a real camera check. Respondents in an app that blocks the camera can still finish on their phone with the QR code before this rejects them.

Set it per project via PUT /api/v1/projects/{id} (config.minAssuranceLevel) — there is no dashboard control for it yet. Leave it at none unless you specifically need a camera check for everyone: it also screens out real people who could only finish without a camera.

Handle a blocked camera yourself (advanced)

If you have your own recovery flow, pass an onCameraBlocked handler to VH.mount(). When an app blocks the camera, the SDK calls your handler instead of showing its own QR panel, and hands control back to you. Leave it out (the usual case) and the SDK's built-in recovery runs.

VH.mount('#vh', {
  siteKey: 'YOUR_PROJECT_ID',
  // optional — omit to use the SDK's built-in QR recovery:
  onCameraBlocked: () => showMyOwnHandoff(),
})

Best practice: start in the system browser

The most reliable fix is to avoid in-app browsers altogether. When you control how respondents arrive (a panel invite, an email, a survey redirect), open your survey in the phone's normal browser, where the camera works on the page and no hand-off is needed. On iOS a web page cannot open the normal browser by itself, so once a respondent is inside an app, the QR code is the method that works on every phone. See Survey integrations for setting up “verify first, then survey” on each platform.

Testing it

You can see a blocked camera on a real Android phone (in-app browsers on iOS usually allow the camera). The quickest way: paste the URL of your page into Telegram → Saved Messages on Android and tap it. The camera is blocked and the QR panel appears. Scan it (or use Open in browser) to finish the check and watch the original tab continue.