Identity, verified.
/ Not guessed.

Use request_type: 'login_identity' for the very first login. The user approves once with FaceID, and you receive in one shot:

{ service_hid, first_name, family_name, date_of_birth }

You save in your DB: your_user_id ↔ service_hid. From the second login onwards, use plain request_type: 'login' — you get only the service_hid back, look it up in your DB, you know it's "Andi user_id 4711", session opens.

Why this matters for social platforms, marketplaces, and banks: first-time signup captures the minimum PII you need (name + DOB) with the user's explicit FaceID consent, while every subsequent login is pure pseudonymous identification. It's the cleanest signup flow available — no email verification, no password reset, no fake accounts.

The service_hid is a per-service pseudonymous identifier, derived client-side on the user's device via HMAC-SHA256(master_secret, "svc:" + your_slug). Same user + same service = always the same sHID. Same user + different service = completely different, unlinkable sHID.

What this means practically:

• You identify the user deterministically across logins — just like Sign-in with Apple.
• You never see the user's real hashID. Neither do we.
• Other services also using hIDcap receive different sHIDs for the same user — you cannot correlate with them, and they cannot correlate with you. Mathematically unlinkable.
• If the user revokes via their hashID app, your sHID stops working — you'll receive a deletion_requested webhook, then a deletion_confirmed after you confirm.

hashID's servers never store the mapping between a real hashID and an sHID. Even a full server compromise reveals nothing about who your users actually are. Best part is no part.

When the user approves a login_identity request, their name and date of birth are encrypted on their device using AES-256-GCM, with a key derived via HKDF from your api_key + a per-service service_salt.

You receive three ciphertext+iv+tag tuples inside the identity field. Decrypt them using the same HKDF derivation on your backend (your api_secret never leaves your servers). We never see the plaintext — we just relay the bytes.

This is how a verification provider can hand you real, government-verified PII without ever being able to read it themselves. That's architectural privacy, not promises.

Same verifier, different protocol. Here we speak OID4VP — the upcoming standard for the EU Digital Identity Wallet. You generate a QR code; the user scans it with any EUDIW-compatible wallet (France Identité, Paradym, Animo, Hovi). The wallet presents a credential directly to our verifier. Live on the French government's playground at tools.playground.france-identite.gouv.fr/hashid/hidcap-verifier. Auto-detects protocol drafts (v1.0, 24, 20, 18) so older wallets still work.

It's the same infrastructure. Our OID4VP verifier accepts any SD-JWT-VC credential — not just age or PID. Swap the DCQL query and you can verify a European Health Insurance Card: institution, country, expiry. Without ever seeing the holder's medical records or social security number. Think of it as proof that hIDcap isn't a one-trick pony — it's a framework.

Two phones. One QR code. No internet between them (optional offline mode). A venue door-person holds phone A showing a QR. The customer scans it with phone B, approves with biometrics, and phone A instantly shows green 18+ badge. Debuts Summer 2026. Built on ISO 18013-5 Device Engagement, plus a proprietary QR-only mode for simple boolean age gates.

Qualified electronic signatures. Use hIDcap to verify the signer's identity with high LoA (via FNMT, Cl@ve, or Docaposte), then PAdES-LTV-sign their PDF server-side. Legally equivalent to a handwritten signature under eIDAS. Rolling out after Desteba's SGAD Service Provider registration completes (Q3 2026).

No. Each tab is a standalone flow you can adopt independently. Most platforms start with QR-based age-gating, add Push when their users have accounts, layer in EUDIW for EU-wide interop, and pull in hIDage / hIDsign as adjacent products mature. One API key covers everything you're approved for.

As little as possible. For a yes/no age check, we see a boolean. For login, we see the user's hashID and a timestamp. For identity, we see only the exact claims you requested (e.g. family_name, given_name). Our servers are in the EU. We do not store PII from verified credentials — ephemeral session data only. Whatever is not needed is discarded before the response returns.

Pricing is volume-tiered and depends on your use case. Reach out via the form below — we'll send exact pricing plus a two-week sandbox key. No credit card upfront. Switchers from AI-estimation vendors get preferred terms.