Verifieer jezelf op je telefoon. Geen app nodig.

• app: weergavenaam van de partnerapp binnen Verihop (max. 80 tekens).
• header: korte verificatietitel die de gebruiker ziet (max. 120 tekens).
• fields: gevraagde veldtokens; bij leeg/ontbrekend gebruikt Verihop legalName en over18.
• callback: basis-retour-URL uit POST /v1/sessions. Verihop opent deze na afronding en voegt session_id, result_token (success path) en optioneel callback_jwt toe; verplicht en gevalideerd tegen je productie-allowlist.

• Authorization: partner-API-key in bearer-formaat.
• Content-Type: gebruik application/json voor request body parsing.
• Idempotency-Key: retry-key voor create-session dedupe; stuur UUID v4/v7 en hergebruik alleen voor retries met dezelfde payload.

{
  "session_id": "sess_123",
  "expires_at": 1730000000,
  "jwt": "",
  "launch_url": "https://www.verihop.com/verify.html?session_id=sess_123&token=h_abc123",
  "qr_url": "https://www.verihop.com/verify.html?session_id=sess_123&token=h_abc123",
  "status_url": "https://api.verihop.com/v1/sessions/sess_123",
  "requested_claims": ["legalName", "over18"],
  "assurance_required": "basic",
  "deep_link": "verihop://share?session="
}

• session_id: unieke sessie-ID voor tracking en result retrieval.
• expires_at: vervaltijd van de sessie (Unix epoch seconds).
• launch_url: primaire URL voor knoppen, QR-codes, e-mail, SMS, webflows en native appflows.
• qr_url: QR-veilige URL; momenteel gelijk aan launch_url.
• jwt: ondertekende sessietoken voor Verihop. Partnerclients valideren deze token normaal niet direct.
• deep_link: legacy/native-only compatibiliteitsveld voor installed-app integraties.

• 401 missing_bearer_token, 401 invalid_api_key
• 403 customer_inactive
• 400 missing_callback_url, invalid_callback_url, callback_host_not_allowed
• 400 field_not_allowed, invalid_field_token, request_too_large
• 409 idempotency_key_conflict, idempotency_key_in_progress
• 429 rate_limit_exceeded, daily_quota_exceeded

{
  "session_id": "sess_123",
  "status": "issued",
  "issued_at": 1730000000,
  "expires_at": 1730000300,
  "last_status": null,
  "last_status_at": null,
  "result_available": false,
  "result_token_expires_at": null
}

{
  "keys": [
    {
      "kty": "RSA",
      "kid": "kid_2025_01",
      "alg": "RS256",
      "use": "sig",
      "n": "...",
      "e": "AQAB"
    }
  ]
}

{
  "session_id": "sess_123",
  "status": "success",
  "result": {
    "legalName": "Jane Doe",
    "over18": "yes"
  }
}

• 401 missing_bearer_token, invalid_api_key, missing_result_token
• 403 customer_mismatch, invalid_result_token
• 410 result_token_expired
• 409 result_token_used
• 404 result_not_available, session_not_found

legalName, dateOfBirth, over18, over21, document, passport, residencePermit

legalName, dateOfBirth, over18, over21, documentType, documentNumber, documentExpiry, documentCountry, documentNationality, nationality

Ja. Je backend maakt een sessie met POST /v1/sessions en toont de teruggegeven qr_url als QR op de desktoppagina. De gebruiker scant die QR met de telefoon en Verihop opent de beste beschikbare ervaring.

De beste UX is direct launch: encodeer de teruggegeven qr_url. Dit is dezelfde universele HTTPS-handoff als launch_url en ondersteunt app, lichte ervaring en webfallback.

Ja. Verihop gebruikt dezelfde launch_url op beide platformen. De callback-vorm is ook gelijk: Verihop voegt session_id, success-path result_token en optioneel callback_jwt toe.

If you use a custom callback such as ridenow://verified, the Android partner app must declare an intent filter for that scheme and host. If you use an https:// callback for desktop or web-started flows, treat it as a backend endpoint unless your Android app owns that domain with verified App Links.

Use an https:// callback endpoint on your backend. After Verihop completes, your server receives session_id and result_token, then fetches GET /v1/sessions/{id}/result server-to-server.

Nee. Die token is bedoeld voor Verihop. Partners behandelen deze als opaque transportdata en gebruiken launch_url om Verihop te starten.

Callback query parameters are transport metadata only. Verified personal data is intentionally not sent in callback URLs. Your backend must exchange the one-time result_token to fetch the result payload securely. If enabled, callback_jwt can be verified via JWKS for callback authenticity.

Yes, on partner backend when present. Verify signature and claims using Verihop JWKS at GET /.well-known/jwks.json. Validate issuer/audience/expiry and ensure JWT claims match callback query values.

No. Keep API keys server-side and fetch results from your backend only. The frontend/web client should only handle UI and pass state to your backend session.

Create a new session when a session expires or the user abandons the flow. result_token is short-lived and single-use; if consumed or expired, restart with a new POST /v1/sessions.

Provide a fallback page behind your QR flow that can explain how to install/open Verihop and then continue. After install, create a new session and show a fresh QR (do not reuse stale sessions).

POST /v1/sessions supports Idempotency-Key for retry-safe create-session calls: same key + same payload replays the original response, while same key + different payload returns 409 idempotency_key_conflict. Misuse is further mitigated with API-key auth, callback allowlist policy, field allowlist checks, per-customer rate limits/quota, short session TTL, and one-time result_token.