API-Referenz
Die API-Referenz zur Identitätsverifizierung.
Jeder Endpunkt, den Sie aufrufen können, jedes Feld, das Sie zurückerhalten, und was Sie mit einem Webhook tun, sobald er eintrifft. Für exakte Feldtypen gilt das Live-OpenAPI-Dokument unter /docs auf Ihrem eigenen API-Origin als maßgebliche Quelle – diese Seite ist die Version in einfacher Sprache.
Basis-URL und Umgebungen
Eine Basis-URL. Zwei Umgebungen.
Jede Anfrage geht an denselben Host. In welcher Umgebung Sie sich befinden, wird ausschließlich dadurch bestimmt, welchen API-Schlüssel Sie senden.
| Basis-URL (diese Dokumentation) | https://api.shieldid.ca — illustrative; your production API origin is published together with your API keys. |
|---|---|
| Auth-Header | X-Api-Key: <Ihr Schlüssel>, bei jeder Anfrage außer den beiden unten genannten öffentlichen Endpunkten. |
| Präfix des Sandbox-Schlüssels | vk_sand_… – Sitzungen, die mit diesem Schlüssel erstellt werden, erhalten den Stempel environment: "sandbox" und werden nie abgerechnet. |
| Präfix des Produktionsschlüssels | vk_live_… – dieselben Anfragen, abgerechnet gemäß Ihrem Plan. |
| Inhaltstyp | application/json bei jedem Request-Body und jeder Antwort. |
Endpunkte
Die gesamte v1-Oberfläche.
Sechs JSON-Endpunkte sowie eine gehostete Seite und eine öffentliche Prüfung von Nachweisen, die gar kein JSON sind – Sie verlinken lediglich darauf.
| Endpoint | Auth | What it does |
|---|---|---|
| POST /v1/sessions | X-Api-Key | Erstellt eine Verifizierungssitzung. Erfordert eine return_url und eine webhook_url. Gibt session_id, verification_url und status: "PENDING" zurück. |
| GET /v1/sessions/{id} | X-Api-Key | Status und wichtigste Felder einer Sitzung: status, confidence, environment. |
| GET /v1/sessions/{id}/result | X-Api-Key | Das vollständige Ergebnis, sobald eine Sitzung VERIFIED oder FAILED erreicht: person, Ergebnisse je Prüfung, confidence, verified_until. |
| DELETE /v1/sessions/{id} | X-Api-Key | Brechen Sie eine Sitzung ab, die noch PENDING oder IN_PROGRESS ist. Eine Sitzung, die bereits VERIFIED, FAILED oder EXPIRED ist, kann nicht abgebrochen werden. |
| GET /v1/credentials/{token} | None — public | Prüfen Sie, ob ein verifizierter Nachweis derzeit gültig ist. Kein API-Schlüssel erforderlich, daher aus dem Browser aufrufbar. Hinweis: Die aktuelle Antwort enthält zusätzlich den Namen der verifizierten Person sowie Dokumenttyp und -land, nicht nur ein Gültig/Ungültig-Kennzeichen – geben Sie diesen Link nicht an Dritte weiter, die diese Angaben nicht sehen sollen. |
| GET /v1/pricing/{country} | X-Api-Key | Preise pro Land für einen zweistelligen Ländercode nach ISO 3166-1. |
| /v/{session_id} | Die gehostete Verifizierungsseite – die verification_url, die eine Sitzung zurückgibt. Auf dem Desktop wird ein QR-Code angezeigt; durch Scannen erhält das Smartphone des Antragstellers denselben Link, um Dokument und Selfie aufzunehmen. |
|---|---|
| /c/{session_id} | Eine öffentliche, nicht authentifizierte Seite zur Prüfung von Nachweisen für eine verifizierte Sitzung. Hinweis: Die aktuelle Antwort enthält zusätzlich den Namen der verifizierten Person sowie Dokumenttyp und -land, nicht nur ein Gültig/Ungültig-Kennzeichen – geben Sie diesen Link nicht an Dritte weiter, die diese Angaben nicht sehen sollen. |
| /docs | Die aktuelle, interaktive OpenAPI-Referenz für den API-Ursprung Ihres Kontos. |
Eine Sitzung erstellen
POST /v1/sessions, von Anfang bis Ende.
Die Anfrage und genau das, was zurückkommt.
curl -X POST https://api.shieldid.ca/v1/sessions \
-H "X-Api-Key: vk_sand_your_key" \
-H "Content-Type: application/json" \
-d '{
"return_url": "https://yourapp.example/verified",
"webhook_url": "https://yourapp.example/hooks/shieldid",
"expected_name": "Jordan Smith",
"locale": "en",
"metadata": { "application_id": "app_9182" }
}'| return_url | string, erforderlich — Wohin der Antragsteller nach Abschluss zurückgeleitet wird. Muss http oder https sein. |
|---|---|
| webhook_url | string, erforderlich — Wohin das signierte Ergebnis zugestellt wird. Siehe Webhooks weiter unten. |
| expected_name | string, erforderlich — Der Name, den Sie auf dem Dokument erwarten; er dient dem Abgleich mit den tatsächlichen Angaben im Ausweis. |
| expected_dob / expected_address | string, optional — Wird bei Angabe mit dem Dokument abgeglichen; für die Durchführung einer Verifizierung nicht erforderlich. |
| locale | string, optional — "en" oder "fr". Legt die Sprache der gehosteten Seite fest, die der Antragsteller sieht. |
| metadata | object, optional — Ihre eigenen Referenzdaten – eine Antrags-ID, eine Mandanten-ID, alles, was unverändert im Ergebnis und im Webhook zurückgegeben werden soll. |
Das Ergebnis
GET /v1/sessions/{id}/result – Aufbau der Antwort.
Dieselbe Struktur wird im Webhook-Payload zugestellt, sodass Sie diesen Endpunkt nur selten abfragen müssen.
| session_id | Die ID, die Sie erstellt haben. |
|---|---|
| status | PENDING, IN_PROGRESS, VERIFIED, FAILED oder EXPIRED. |
| environment | "sandbox" oder "production", passend zum Schlüssel, mit dem die Sitzung erstellt wurde. |
| person | Die aus dem Dokument gelesenen Felder: Name, Geburtsdatum, Dokumenttyp, Dokumentland und Jurisdiktion, Adresse. |
| checks | Ein Urteil pro Prüfung – siehe unten. Nie ein einziger undurchsichtiger Score. |
| confidence | Eine einzelne Gesamtzahl für die Verifizierung. Die einzelnen Prüfungen, einschließlich des Gesichtsabgleichs, werden weiterhin separat anhand einer festen Entscheidungsgrenze gemeldet – dieses Feld ersetzt sie nicht. |
| verified_until | Wie lange das Ergebnis bei einer VERIFIED-Sitzung als aktuell gilt. |
| failure_reason | Wird bei einer FAILED-Sitzung gesetzt – zum Beispiel FACE_MATCH_BELOW_THRESHOLD oder CANCELLED_BY_API. Andernfalls null. |
| metadata | Alles, was Sie beim Erstellen der Sitzung gesendet haben, unverändert. |
{
"session_id": "ses_9f2c1a",
"status": "VERIFIED",
"environment": "sandbox",
"person": {
"name": "Jordan Smith",
"dob": "1994-03-11",
"document_type": "drivers_licence",
"document_country": "CA",
"document_jurisdiction": "ON"
},
"checks": {
"document": "PASS",
"liveness": "PASS",
"antispoof": "PASS",
"face_match": "PASS"
},
"confidence": 88,
"verified_until": "2027-03-11T00:00:00Z",
"failure_reason": null,
"metadata": { "application_id": "app_9182" }
}Add-onchecks.document, checks.liveness, checks.antispoof und checks.face_match ergeben jeweils PASS, FAIL oder SKIPPED. Die Watchlist-Prüfung (checks.sanctions – CLEAR, MATCH oder SKIPPED) ist ein Zusatzmodul und erscheint nur bei Konten, die es aktiviert haben.
Lebenszyklus einer Sitzung
Fünf Zustände, ein Pfad.
Eine Sitzung schreitet von selbst voran; Sie steuern den Zustandsautomaten nicht, Sie lesen ihn nur aus.
| PENDING | Erstellt. Niemand hat die verification_url bisher geöffnet. |
|---|---|
| IN_PROGRESS | Die antragstellende Person hat den Link geöffnet und befindet sich irgendwo im Erfassungsablauf. |
| VERIFIED | Alle Prüfungen wurden durchgeführt, und das Ergebnis liegt vor. Endzustand – rufen Sie den Result-Endpunkt auf oder lesen Sie den Webhook. |
| FAILED | Mindestens eine Prüfung wurde nicht bestanden. failure_reason gibt an, welche. Demnächst verfügbar: ein erneuter Versuch, der die Sitzung auf PENDING zurücksetzt – bis dahin behandeln Sie FAILED als Endzustand und erstellen eine neue Sitzung, wenn die antragstellende Person es erneut versuchen möchte. |
| EXPIRED | Niemand hat rechtzeitig abgeschlossen. Sitzungen laufen nach einer Standardfrist (30 Minuten) automatisch ab; erstellen Sie eine neue, um es erneut zu versuchen. |
DELETE /v1/sessions/{id} bricht eine Sitzung im Status PENDING oder IN_PROGRESS vorzeitig ab. Eine Sitzung, die bereits VERIFIED, FAILED oder EXPIRED erreicht hat, kann nicht abgebrochen werden – sie ist bereits abgeschlossen.
Fehler
Wofür Sie planen sollten.
Dies ist die Kurzliste, für die sich die Programmierung heute lohnt. Der vollständige, aktuelle Satz an Fehlercodes und Payloads ist in der Live-OpenAPI unter /docs dokumentiert.
| Status | Code | Meaning |
|---|---|---|
| 401 | UNAUTHORIZED | Der X-Api-Key-Header fehlt. |
| 401 | INVALID_KEY_FORMAT | Der Schlüssel beginnt nicht mit vk_sand_ oder vk_live_ oder stimmt mit keinem Schlüssel des Kontos überein. |
| 403 | FORBIDDEN | Der Schlüssel ist gültig, hat aber keinen Zugriff auf die angeforderte Sitzung oder Ressource. |
| 404 | NOT_FOUND | Es existiert keine Sitzung, kein Zugangsdatensatz und keine Ressource mit dieser ID. |
| 409 | CONFLICT | Die Sitzung befindet sich nicht in einem Zustand, der die Aktion zulässt – zum Beispiel beim Abbrechen einer Sitzung, die bereits VERIFIED ist. |
| 422 | VALIDATION_ERROR | Ein erforderliches Feld fehlt oder ist fehlerhaft – zum Beispiel ist return_url keine gültige http- oder https-URL. |
Webhooks
Signiert, zugestellt, wiederholt.
Wenn eine Sitzung VERIFIED oder FAILED erreicht, sendet ShieldID per POST die oben dokumentierte Struktur an Ihre webhook_url.
- Zugestellt als POST mit einem JSON-Body, der der oben beschriebenen Ergebnisstruktur entspricht.
- Signiert mit HMAC-SHA256 über den rohen Request-Body und in einem X-Bio-Signature-Header gesendet. Prüfen Sie ihn anhand Ihres Webhook-Secrets, bevor Sie der Payload vertrauen.
- Bis zu dreimal mit linearem Backoff wiederholt, wenn Ihr Endpunkt nicht mit einem 2xx-Status antwortet.
- Demnächst verfügbar: ein erneuter Versuch bei FAILED-Sitzungen, der einen zweiten Webhook zustellt, sobald er abgeschlossen ist. Gehen Sie heute von einem Webhook pro Sitzung als Regel aus.
- Die Feldnamen hier entsprechen dieser Referenz. Wenn das tatsächlich Eintreffende anders aussieht, vertrauen Sie der Live-Payload statt dieser Seite und sagen Sie uns Bescheid – die Feldliste wird an die API angepasst, nicht umgekehrt.
Signatur prüfen
import crypto from "node:crypto";
function isValidShieldIdSignature(rawBody, signatureHeader, secret) {
const expected = crypto.createHmac("sha256", secret).update(rawBody).digest("hex");
const provided = signatureHeader || "";
const a = Buffer.from(expected, "hex");
const b = Buffer.from(provided, "hex");
return a.length === b.length && crypto.timingSafeEqual(a, b);
}
// rawBody must be the exact, unparsed request body
app.post("/hooks/shieldid", express.raw({ type: "application/json" }), (req, res) => {
const ok = isValidShieldIdSignature(req.body, req.headers["x-bio-signature"], process.env.SHIELDID_WEBHOOK_SECRET);
if (!ok) return res.status(401).send("invalid signature");
const result = JSON.parse(req.body);
// result.session_id, result.status, result.checks, …
res.status(200).send("ok");
});Idempotenz und Wiederholungen
Bauen Sie Handler, die sich gefahrlos zweimal ausführen lassen.
Es gibt noch keinen eigenen Idempotenzschlüssel – weder bei der Sitzungserstellung noch bei der Webhook-Zustellung.
- Eine wiederholte Webhook-Zustellung kann für dieselbe Sitzung mehrfach eintreffen. Verwenden Sie in Ihrem Handler session_id + status als Schlüssel und gestalten Sie das Schreiben des Ergebnisses idempotent.
- Wiederholen Sie POST /v1/sessions bei einem Timeout nicht blind – prüfen Sie zuerst, ob die Sitzung erstellt wurde, sonst haben Sie am Ende zwei Sitzungen für eine antragstellende Person.
- Ein eigener Idempotency-Key-Header für die Sitzungserstellung ist geplant.
Demnächst verfügbarIdempotency-Key-Unterstützung bei der Sitzungserstellung
Auf dem Laufenden bleiben
Diese Referenz ändert sich. Behalten Sie das Changelog im Blick.
Neue Felder, neue Fehlercodes und Endpunktänderungen werden dort angekündigt, bevor sie hier erscheinen.
Fragen
FAQ zur Referenz.
Weiter
Setzen Sie diese Referenz in die Praxis um.
Folgen Sie dem Quickstart, um der Reihe nach von einem Sandbox-Schlüssel zu einer verifizierten Sitzung und einem signierten Webhook zu gelangen.