Wege zur Integration: API, SDKs und No-Code-Links
Sie müssen keinen Code schreiben, um mit Didit Personen zu verifizieren - nutzen Sie einen No-Code-Link, oder binden Sie ein SDK oder die API ein, wenn Sie Automatisierung wünschen.
Drei Wege. No-Code-Links benötigen überhaupt kein Backend. Die API plus ein Redirect ist die Standardintegration. SDKs bauen den Ablauf in Ihre eigene App ein - und sind der einzige Weg, der NFC unterstützt. Für welchen Weg Sie sich auch entscheiden, holen Sie Ergebnisse mit Webhooks ab.
Sie benötigen keinen Entwickler, um mit Didit die Identitätsverifizierung zu starten. Es gibt eine No-Code-Option, die wenige Minuten dauert, sowie API- und SDK-Optionen für den Fall, dass Sie sie automatisiert in Ihr eigenes Produkt einbinden möchten.
#Kann ich Didit ohne Programmieren nutzen?
Ja. Sobald Sie in der Konsole einen Workflow erstellt haben, können Sie eine Verifizierungssession auf zwei Arten ganz ohne Code generieren:
- Schritt eins stellt den API-Schlüssel aus, mit dem sich Ihr Backend authentifiziert.
- Schritt zwei wählt den Workflow, den jede Session ausführen wird.
- Schritt drei registriert, wohin Ergebnisse gesendet werden, und sendet eine Testübermittlung.
- Schritt vier ist der Code: kopieren Sie den Quickstart für Ihren Stack.
- Verifizierungslink (einmalig)
Erstellen Sie auf der Seite Workflows eine Session direkt in der Konsole. Sie erhalten eine eindeutige URL und einen QR-Code für diese Person - senden Sie ihn per E-Mail, SMS oder über einen beliebigen Kanal, oder lassen Sie den Code vor Ort scannen.
- Wiederverwendbarer Link (Unilink)
Jeder Workflow verfügt außerdem über einen wiederverwendbaren Link, der bei jedem Besuch eine neue Session startet. Platzieren Sie ihn hinter einem Button auf Ihrer Website, drucken Sie ihn als QR-Code für einen Kiosk oder eine Filiale, oder teilen Sie ihn mit Partnern. Siehe wiederverwendbare Links.
Beide Wege umgehen die API und Ihr Backend vollständig - die richtige Wahl für MVPs, manuelle Prüfung, Vor-Ort-Verifizierung oder den Einstieg, bevor Sie etwas Eigenes gebaut haben.
#Wenn Sie Automatisierung wünschen
Wenn das Ergebnis automatisch Ihre eigenen Systeme aktualisieren soll - nicht nur in der Konsole erscheinen soll - benötigen Sie die API oder ein SDK:
| Sie möchten... | Nutzen Sie |
|---|---|
| Nutzer von Ihrer App aus auf eine gehostete Verifizierungsseite umleiten | Einen einzelnen API-Aufruf zum Erstellen einer Session, dann Weiterleitung zur zurückgegebenen URL |
| Verifizierung in Ihre Web-App einbetten | Das JavaScript SDK oder das In-Context-iFrame |
| Innerhalb einer nativen iOS-, Android-, Flutter- oder React-Native-App verifizieren | Das passende native SDK - erforderlich für NFC |
| Verifizierung zu WordPress/WooCommerce oder Shopify hinzufügen | Das WordPress/WooCommerce- oder Shopify-Plugin - kein Code erforderlich |
| In ein Automatisierungstool einbinden | Die API über Zapier, n8n, oder jedes Tool, das eine HTTP-Anfrage senden und einen Webhook empfangen kann |
| Ergebnisse in dem Moment an Ihr Backend pushen, in dem sie bereit sind | Webhooks |
| Einzelne Prüfungen selbst ausführen (Batch-Verarbeitung, eigene Capture-UI) | Die eigenständigen APIs, direkt aufgerufen statt über eine Workflow-Session |
#Den Link selbst versenden
Wenn Sie eine Session über die API erstellen, gibt Didit die Verifizierungs-URL zurück - und die Zustellung liegt dann bei Ihnen. Sie aus Ihrem eigenen Produkt zu senden, mit eigenem Text und eigenem Branding, ist ohnehin meist die bessere Erfahrung: die Person vertraut Ihnen bereits, und eine Nachricht von einem unbekannten Absender kostet Conversion.
Wenn Didit die Person stattdessen per E-Mail erreichen soll, übergeben Sie Kontaktdaten beim Erstellen der Session. Bestätigen Sie, was für Ihr Setup unterstützt wird, statt es anzunehmen, und beachten Sie, dass die E-Mail-Sprache ein eigenes Feld ist, getrennt von der Sprache des Ablaufs. Siehe die Verifizierungssprache festlegen.
#Zwischen gehostet, eingebettet und nativ wählen
| Gehostetes Redirect | Eingebettet (Web-SDK / iFrame) | Natives SDK | |
|---|---|---|---|
| Erforderlicher Code | Minimal | Moderat | Am meisten |
| Nutzer verlässt Ihre App | Ja | Nein | Nein |
| NFC-Chip-Auslesung | Nein | Nein | Ja |
| Bestes Kameraverhalten | Gut | Gut | Am besten |
| Eigene Domain entfernt Didit aus der URL | Ja | n/a | n/a |
Wenn Ihnen NFC wichtig ist, entscheidet diese Zeile darüber: der Chip kann von einer Browserseite aus nicht ausgelesen werden. Siehe NFC-Chip-Verifizierung.
Welche eingebetteten Optionen in Ihrem Plan verfügbar sind, sollten Sie mit Ihrem Didit-Ansprechpartner klären, bevor Sie ein Projekt darauf ausrichten.
#Eigenständige APIs vs. Workflow-Sessions
Eine Workflow-Session führt die Prüfungen zusammen aus, erzeugt eine aggregierte Entscheidung und greift für die vier Free-Tier-Features auf die Kontingente pro Feature zurück. Ein eigenständiger API-Aufruf führt eine Prüfung auf von Ihnen bereitgestellten Daten aus, gibt nur dieses Ergebnis zurück und wird pro Aufruf ohne Freikontingent abgerechnet.
Eigenständige Aufrufe sind das richtige Werkzeug für Batch-Verarbeitung, für eine selbst gebaute Capture-UI, oder für eine Prüfung, die Sie außerhalb eines Onboarding-Ablaufs ausführen möchten. Sie sind das falsche Werkzeug, wenn Sie das Freikontingent nutzen wollten.
#Testen, bevor Sie live gehen
Erstellen Sie eine separate Anwendung im Sandbox-Modus zum Testen - jede Anwendung hat ihren eigenen API-Schlüssel und eigene Workflows, sodass Testverkehr niemals Live-Daten berührt, und Sandbox-Sessions kosten nichts, während Sie jedes Ergebnis erzwingen können. Siehe Testen in der Sandbox.
#Nächste Schritte
- Richten Sie zuerst einen Workflow ein, falls noch nicht geschehen: einen Verifizierungs-Workflow erstellen
- Erhalten Sie Ergebnisse in dem Moment, in dem sie bereit sind: Verifizierungsergebnisse mit Webhooks erhalten
- Wo Sie Ihren API-Schlüssel finden: Ihre API-Schlüssel verwalten
- Wenn etwas einen Fehler zurückgibt: API-Fehler und was sie bedeuten