Zum Hauptinhalt springen
ShieldID

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.

Jede Anfrage in dieser Referenz setzt diese beiden Dinge voraus.
Basis-URL (diese Dokumentation)https://api.shieldid.ca — illustrative; your production API origin is published together with your API keys.
Auth-HeaderX-Api-Key: <Ihr Schlüssel>, bei jeder Anfrage außer den beiden unten genannten öffentlichen Endpunkten.
Präfix des Sandbox-Schlüsselsvk_sand_… – Sitzungen, die mit diesem Schlüssel erstellt werden, erhalten den Stempel environment: "sandbox" und werden nie abgerechnet.
Präfix des Produktionsschlüsselsvk_live_… – dieselben Anfragen, abgerechnet gemäß Ihrem Plan.
Inhaltstypapplication/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.

JSON-Endpunkte unter /v1.
EndpointAuthWhat it does
POST /v1/sessionsX-Api-KeyErstellt 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-KeyStatus und wichtigste Felder einer Sitzung: status, confidence, environment.
GET /v1/sessions/{id}/resultX-Api-KeyDas vollständige Ergebnis, sobald eine Sitzung VERIFIED oder FAILED erreicht: person, Ergebnisse je Prüfung, confidence, verified_until.
DELETE /v1/sessions/{id}X-Api-KeyBrechen 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 — publicPrü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-KeyPreise pro Land für einen zweistelligen Ländercode nach ISO 3166-1.
Seiten, auf die Sie verlinken, kein JSON, das Sie verarbeiten.
/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.
/docsDie 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.

bash
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" }
  }'

POST /v1/sessions – Anfragefelder.
return_urlstring, erforderlich — Wohin der Antragsteller nach Abschluss zurückgeleitet wird. Muss http oder https sein.
webhook_urlstring, erforderlich — Wohin das signierte Ergebnis zugestellt wird. Siehe Webhooks weiter unten.
expected_namestring, erforderlich — Der Name, den Sie auf dem Dokument erwarten; er dient dem Abgleich mit den tatsächlichen Angaben im Ausweis.
expected_dob / expected_addressstring, optional — Wird bei Angabe mit dem Dokument abgeglichen; für die Durchführung einer Verifizierung nicht erforderlich.
localestring, optional — "en" oder "fr". Legt die Sprache der gehosteten Seite fest, die der Antragsteller sieht.
metadataobject, 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.

Felder der obersten Ebene.
session_idDie ID, die Sie erstellt haben.
statusPENDING, IN_PROGRESS, VERIFIED, FAILED oder EXPIRED.
environment"sandbox" oder "production", passend zum Schlüssel, mit dem die Sitzung erstellt wurde.
personDie aus dem Dokument gelesenen Felder: Name, Geburtsdatum, Dokumenttyp, Dokumentland und Jurisdiktion, Adresse.
checksEin Urteil pro Prüfung – siehe unten. Nie ein einziger undurchsichtiger Score.
confidenceEine 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_untilWie lange das Ergebnis bei einer VERIFIED-Sitzung als aktuell gilt.
failure_reasonWird bei einer FAILED-Sitzung gesetzt – zum Beispiel FACE_MATCH_BELOW_THRESHOLD oder CANCELLED_BY_API. Andernfalls null.
metadataAlles, was Sie beim Erstellen der Sitzung gesendet haben, unverändert.
json
{
  "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.

status-Werte, in der Reihenfolge.
PENDINGErstellt. Niemand hat die verification_url bisher geöffnet.
IN_PROGRESSDie antragstellende Person hat den Link geöffnet und befindet sich irgendwo im Erfassungsablauf.
VERIFIEDAlle Prüfungen wurden durchgeführt, und das Ergebnis liegt vor. Endzustand – rufen Sie den Result-Endpunkt auf oder lesen Sie den Webhook.
FAILEDMindestens 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.
EXPIREDNiemand 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.

HTTP-Status, Fehlercode und was er bedeutet.
StatusCodeMeaning
401UNAUTHORIZEDDer X-Api-Key-Header fehlt.
401INVALID_KEY_FORMATDer Schlüssel beginnt nicht mit vk_sand_ oder vk_live_ oder stimmt mit keinem Schlüssel des Kontos überein.
403FORBIDDENDer Schlüssel ist gültig, hat aber keinen Zugriff auf die angeforderte Sitzung oder Ressource.
404NOT_FOUNDEs existiert keine Sitzung, kein Zugangsdatensatz und keine Ressource mit dieser ID.
409CONFLICTDie Sitzung befindet sich nicht in einem Zustand, der die Aktion zulässt – zum Beispiel beim Abbrechen einer Sitzung, die bereits VERIFIED ist.
422VALIDATION_ERROREin 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

javascript
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.