Hosted verification links

The integration with no client code at all. You mint a link, send it to the person, and they complete the capture on a page we host. You never ship a key, never build a camera UI, and never handle the images.

This is the right answer whenever a key would otherwise end up somewhere it can be read — a browser bundle, a mobile app, a WhatsApp flow, an email to a customer.

Mint a link

Free — you are charged when the verification completes, not when the link is created:

bash
curl -X POST https://liveliness.neetix.in/v1/links \
  -H "Authorization: Bearer $NEETIX_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"label":"application-4821","expires_hours":72}'
json
{
  "token": "...",
  "url": "https://liveliness.neetix.in/verify/?t=..."
}

Send that url. Use label to carry your own identifier — it comes back with the result, and it is how you match a completion to an application.

What the user sees

The hosted page drives the whole flow: capture the selfie, capture the ID, and submit. Behind it are two public endpoints you do not normally call yourself:

MethodPathPurpose
GET/v1/links/{token}Link state: pending, completed or expired
POST/v1/links/{token}/verifymultipart person + card

They are public by design — the user has no key — and IP rate-limited to 30 requests an hour.

Read the result

Poll your links, or let the webhook tell you:

bash
curl https://liveliness.neetix.in/v1/links \
  -H "Authorization: Bearer $NEETIX_KEY"
json
{
  "links": [
    {
      "token": "...",
      "url": "https://liveliness.neetix.in/verify/?t=...",
      "label": "application-4821",
      "status": "completed",
      "result": { "verdict": "approved", "confidence": 97.3, "liveness": 96.1, "warnings": [] },
      "expires_at": "...",
      "completed_at": "..."
    }
  ]
}

The webhook event is link.completed. Prefer it over polling — a poll loop across thousands of pending links is the kind of thing that works in testing and falls over at volume.

Rules worth knowing before you build on it

Links are single-use

A second submit on the same token answers 410, and so does any submit past expires_hours. If a genuine user's first attempt fails — bad light, wrong document — they cannot retry on that link. Mint a fresh one, and design your flow so support can do that without a developer.

  • The completing verification is charged to you, the link owner, at the face_match cost of 2 credits.
  • expires_hours is yours to choose. Short windows reduce the chance of a link being forwarded; long windows reduce the number of customers who need a second one. 72 hours is a reasonable default for an onboarding journey.
  • The result on the link is a compact summary (verdict, confidence, liveness, warnings), not the full face-match body. If you need the complete forensics for an audit file, call /v1/face/face-match server-to-server instead.

Next