Verifizieren auf dem Gerät. Keine App nötig.

• app: Anzeigename der Partner-App in Verihop (max. 80 Zeichen).
• header: kurzer Verifikationstitel für den Nutzer (max. 120 Zeichen).
• fields: angefragte Feldtokens; leer/fehlend fällt auf legalName und over18 zurück.
• callback: Basis-Rücksprung-URL aus POST /v1/sessions. Verihop öffnet sie nach Abschluss und ergänzt session_id, result_token (Success Path) und optional callback_jwt; erforderlich und gegen deine Produktions-Allowlist validiert.

• Authorization: Partner-API-Key im Bearer-Format.
• Content-Type: nutze application/json für Request-Body-Parsing.
• Idempotency-Key: Retry-Key für Create-Session-Dedupe; sende UUID v4/v7 und nutze ihn nur für Retries derselben 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: eindeutige Session-ID für Tracking und Ergebnisabruf.
• expires_at: Ablaufzeit der Session (Unix Epoch Seconds).
• launch_url: primäre URL für Buttons, QR-Codes, E-Mail, SMS, Webflows und native Appflows.
• qr_url: QR-sichere URL; aktuell identisch mit launch_url.
• jwt: signierter Session Token für Verihop. Partnerclients validieren diesen normalerweise nicht direkt.
• deep_link: Legacy/native-only Kompatibilitätsfeld für Installed-App-Integrationen.

• 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

Yes. Your backend creates a session using POST /v1/sessions, then renders the returned qr_url inside a QR shown on the desktop page. The user scans that QR with their phone and Verihop opens the best available experience.

Best UX is direct launch: encode the returned qr_url. It is the same universal HTTPS handoff as launch_url and supports app, lightweight, and web fallback paths.

Yes. Verihop uses the same launch_url on both platforms. Your callback shape is also the same: Verihop appends session_id, success-path result_token, and optional callback_jwt.

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.

Nein. Dieser Token ist für Verihop bestimmt. Partner behandeln ihn als opaque Transportdaten und nutzen launch_url, um Verihop zu 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.