Zum Hauptinhalt springen
ShieldID

Quickstart

Der Quickstart zur Identitätsverifizierung.

Vom Sandbox-Schlüssel bis zum ersten signierten Webhook, der Reihe nach. Jeder Schritt hat ein funktionierendes Beispiel – kopieren Sie es, setzen Sie Ihren eigenen Schlüssel und Ihre eigenen URLs ein und führen Sie es aus.

Schritt für Schritt

Sieben Schritte, ein Nachmittag.

  1. Sandbox-Schlüssel erhalten

    Sandbox-Schlüssel (Präfix vk_sand_) werden auf Anfrage ausgestellt, solange die Selbstregistrierung noch entwickelt wird. Fragen Sie über das Kontaktformular an – die meisten Anfragen werden noch am selben Werktag bearbeitet. Sandbox-Sitzungen werden nie abgerechnet, es gibt also keinen Grund, mit dem Start zu warten.

  2. Erstellen Sie Ihre erste Session

    Ein Aufruf. Senden Sie eine return_url (wohin die antragstellende Person nach Abschluss gelangt) und eine webhook_url (wohin das signierte Ergebnis gesendet wird). Sie erhalten eine session_id und eine verification_url zurück.

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

  3. Übergeben Sie der antragstellenden Person den Link

    Öffnen Sie die verification_url, und Sie sehen die gehostete Seite. In einem Desktop-Browser wird ein QR-Code angezeigt. Beim Scannen wird derselbe Link an ein Smartphone übergeben, wo das eigentliche Foto des Dokuments, die Liveness-Prüfung und das Selfie stattfinden. Probieren Sie es gleich auf Ihrem eigenen Smartphone aus.

  4. Einen Webhook-Endpunkt bereitstellen

    Richten Sie webhook_url auf eine Route, die einen POST akzeptiert, den rohen Request-Body liest (Sie benötigen ihn unverarbeitet, um die Signatur zu prüfen) und einen 2xx-Status zurückgibt. Andernfalls wiederholt ShieldID die Zustellung bis zu dreimal.

    javascript
    import express from "express";
    const app = express();
    
    app.post("/hooks/shieldid", express.raw({ type: "application/json" }), (req, res) => {
      // Verify the signature before you trust this body — see the next step.
      console.log("Received a webhook:", req.body.toString());
      res.status(200).send("ok");
    });
    
    app.listen(3000);

  5. Signatur prüfen

    Verarbeiten Sie einen Webhook-Body erst, wenn Sie geprüft haben, dass er tatsächlich von ShieldID stammt. Berechnen Sie mit Ihrem Webhook-Secret einen HMAC-SHA256 über den rohen Body und vergleichen Sie ihn mit dem Header X-Bio-Signature.

    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");
    });

  6. Ergebnis lesen

    Die Webhook-Payload enthält bereits alles, was Sie benötigen. Wenn Sie das Ergebnis lieber selbst abrufen möchten, etwa nach einer Weiterleitung, rufen Sie den Result-Endpunkt direkt auf.

    bash
    curl https://api.shieldid.ca/v1/sessions/ses_9f2c1a/result \
      -H "X-Api-Key: vk_sand_your_key"
    
    # → { "session_id": "ses_9f2c1a", "status": "VERIFIED", "checks": { "document": "PASS", … }, … }

  7. FAILED und einen erneuten Versuch behandeln

    Eine Session, die auf FAILED endet, enthält eine failure_reason. Zeigen Sie der antragstellenden Person eine hilfreiche Meldung an. Demnächst verfügbar: ein erneuter Versuch für eine FAILED-Session, um sie auf PENDING zurückzusetzen. Behandeln Sie FAILED derzeit als Endzustand und erstellen Sie eine neue Session, wenn die antragstellende Person es erneut versuchen möchte.

Bevor Sie den Schalter umlegen

Gehen Sie in Produktion.

Die Struktur der Anfrage ändert sich zwischen Sandbox und Produktion nie, nur der Schlüssel. Prüfen Sie Folgendes, bevor Sie eine echte antragstellende Person durch eine vk_live_-Session schicken.

  • Ersetzen Sie vk_sand_ durch einen vk_live_-Schlüssel. An der Anfrage ändert sich sonst nichts.
  • Richten Sie webhook_url auf einen echten, dauerhaft erreichbaren Endpunkt, der die Signatur prüft, nicht auf einen Request-Bin oder einen Laptop.
  • Behandeln Sie in Ihrer App alle drei Endzustände: VERIFIED, FAILED und EXPIRED, nicht nur den Idealfall.
  • Stellen Sie sicher, dass Ihre return_url die Query-Parameter session_id und status ausliest, die ShieldID bei der Weiterleitung anhängt.
  • Prüfen Sie die aktuellen Preise mit GET /v1/pricing/{country} oder auf der Preisseite, damit die Kosten in der Produktion keine Überraschung sind.
  • Halten Sie Sandbox-Schlüssel von allem fern, was eine echte antragstellende Person erreichen könnte. Eine Sandbox-Session ist kostenlos, weil sie nicht real ist.

Fragen

FAQ zum Quickstart.

Erste Schritte

Führen Sie den ersten Schritt gleich jetzt aus.

Fordern Sie einen Sandbox-Schlüssel an, fügen Sie den ersten cURL-Befehl in ein Terminal ein, und Sie sind den meisten Integrationen bereits einen Schritt voraus.