> ## Documentation Index
> Fetch the complete documentation index at: https://docs.verifyyou.com/llms.txt
> Use this file to discover all available pages before exploring further.

# FAQ

> Common questions about verifying, keys, returning users, and data.

<AccordionGroup>
  <Accordion title="What does “verified” actually mean?">
    That the person passed two checks: they're a **live human** (a face check,
    not a photo, video, mask, or generated face) and they're **unique** (their
    face doesn't match someone else who already verified in the
    [scope you chose](/v3/concepts/humanness-and-uniqueness), your company or
    the whole network). A confirmation returns `verified: true` only when both
    pass.
  </Accordion>

  <Accordion title="Can I trust the ?vyc value on the return URL?">
    No. Treat it as a UI hint only. Anyone can edit a URL. Always send the
    `vyt` token to your backend and
    [confirm it](/v3/api/confirmations) with your secret key. That result is
    authoritative.
  </Accordion>

  <Accordion title="What's the difference between publishable and secret keys?">
    The **publishable key** (`pk_…`) is safe in the browser and is what the SDK
    uses to start a verification. The **secret key** (`sk_…`) stays on your
    server and is required to confirm tokens, lock confirmations, and attach
    identities at initialize. Never ship a secret key to the client.
  </Accordion>

  <Accordion title="How do test and live modes work?">
    Each key comes in a test and a live flavor (`pk_test_…` / `pk_live_…`,
    `sk_test_…` / `sk_live_…`). Test keys run a sandbox flow that creates test
    users. Build against them freely. Switch to live keys to verify real people.
  </Accordion>

  <Accordion title="Why did a returning user get blocked?">
    Most often it's a **guest** whose device ID is gone: they cleared the
    browser, switched devices, or used a private window. They look like a new
    person, but their face is still on record, so they collide with their own
    earlier verification. Verify repeat users as
    [members](/v3/concepts/members-vs-guests) (a verified phone or email) so
    they can be recognized and re-linked instead of blocked.
  </Accordion>

  <Accordion title="Do users have to verify every time?">
    No. Within your verification's skip window, someone who already passed
    completes almost instantly. **Members** are also recognized on new
    devices: their face is matched and they sign back in with their number or
    email to re-assert their claim. **Guests** are recognized only by the
    device ID in their browser, so they re-verify more often. See
    [Returning users](/v3/concepts/returning-users).
  </Accordion>

  <Accordion title="What if my user is on a desktop?">
    The flow runs in place with their webcam. If they'd rather use their phone,
    one click shows a QR code that moves the same session to their phone's
    browser, and the desktop follows along in realtime and returns to your site
    automatically when they finish. See
    [Humanness and uniqueness](/v3/concepts/humanness-and-uniqueness#any-device-including-desktop).
  </Accordion>

  <Accordion title="How do I tie a verification to my own user?">
    Pass `external_id` (and optionally `phone`/`email`) at
    [initialize](/v3/api/initialize) from your server. The `external_id` comes
    back on the confirmation. See [Account linking](/v3/advanced/account-linking).
  </Accordion>

  <Accordion title="I have a one-time form and don't want resubmissions. What do I use?">
    [Lock the confirmation](/v3/api/confirmations#lock-a-confirmation-optional)
    once you've accepted it. The token becomes invalid for that verification, so
    re-checking it returns `verified: false`.
  </Accordion>
</AccordionGroup>