Sollte ich die gehostete Seite oder das Widget verwenden?

Beginnen Sie mit der gehosteten Seite: Sie benötigt nur einen API-Aufruf und keinen clientseitigen Code. Greifen Sie nur dann zum Widget, wenn es Ihnen so wichtig ist, den Antragsteller in Ihrem eigenen Layout zu halten, dass Sie eine iframe-Integration und die aktuellen Einschränkungen bei den Callbacks in Kauf nehmen.

Warum werden die Callbacks onComplete und onCancel des Widgets nicht ausgelöst?

Die gehostete Seite im iframe sendet die Nachrichten, auf die das Widget wartet, noch nicht. Das ist eine bekannte Lücke und kein Konfigurationsfehler auf Ihrer Seite. Verwenden Sie bis zur Behebung die return_url und den Webhook, die beide heute funktionieren.

Ist es sicher, meinen API-Schlüssel im init()-Aufruf des Widgets zu verwenden?

Technisch akzeptiert das Widget ihn, wir raten aber davon ab: Ein unverschlüsselter Schlüssel in clientseitigem JavaScript ist für jeden sichtbar, der den Quelltext ansieht. Erstellen Sie die Session stattdessen serverseitig und übergeben Sie dem Widget die resultierende verification_url.

Gibt es eine React- oder Mobile-Komponente?

Noch nicht. Das Web-Widget ist heute ein einfaches Script-Tag; native iOS- und Android-SDKs sind geplant. Die gehostete Seite funktioniert in der Zwischenzeit in einer WebView oder im System-Browser.

Unterstützt das Widget Französisch?

Ja. Übergeben Sie locale: "fr" genauso wie bei der API, und der Ablauf im iframe wird auf Französisch dargestellt.

SDKs

Das SDK für die Ausweisprüfung und der Weg ohne SDK.

Die meisten Integrationen benötigen überhaupt kein SDK, denn die gehostete Seite erledigt die Arbeit. Das Web-Widget ist für den Fall da, dass der Ablauf in Ihrer eigenen Seite bleiben soll. Native Mobile-SDKs folgen als Nächstes.

Zur Kurzanleitung API-Referenz

Der Weg ohne SDK

Die gehostete Seite benötigt auf keiner Plattform ein SDK.

POST /v1/sessions gibt eine verification_url zurück. Senden Sie sie der antragstellenden Person auf dem Weg, auf dem Ihr Produkt ohnehin Links verschickt, etwa per E-Mail, SMS, In-App-Weiterleitung oder als QR-Code auf einem Bildschirm. ShieldID übernimmt Erfassung, Liveness-Prüfung und Selfie auf dem eigenen Smartphone der Person.

Funktioniert über eine Web-App, den System-Browser oder die WebView einer nativen App, einen E-Mail-Link oder einen QR-Code an einem Kiosk, ohne dass etwas installiert werden muss
White-Label-Branding in qualifizierten Tarifen, damit es nicht wie eine Übergabe an einen Dritten wirkt
Ergebnisse erreichen Sie über die Weiterleitung zur return_url und den signierten Webhook, ohne dass clientseitige Callbacks eingerichtet werden müssen

Zum Endpunkt der gehosteten Seite

Das Web-Widget

Ein kleines Skript, das den gehosteten Verifizierungsablauf in einem iframe auf Ihrer Seite darstellt, statt die antragstellende Person von dort wegzuschicken.

Was heute funktioniert

TLVerify.init({ apiKey, containerId, returnUrl, cancelUrl, webhookUrl, locale, theme }) erstellt eine Session und bindet sie in ein von Ihnen gewähltes Element ein
Führt denselben Erfassungsablauf wie die gehostete Seite aus, innerhalb Ihres Layouts, mit Ihrer accentColor und Ihrem Logo
Funktioniert heute für das Erstellen einer Session und die Inline-Darstellung des Ablaufs

Callbacks bei Abschluss

Demnächst verfügbar

onComplete, onCancel, onStep und die automatische Größenanpassung des iframes gehören zur Schnittstelle des Widgets, aber im Ablauf löst sie bislang nichts aus. Bauen Sie keine Logik, die darauf angewiesen ist, dass sie ausgelöst werden. Nutzen Sie stattdessen die Return-URL und den Webhook, die beide heute funktionieren.

Ein Hinweis zu API-Schlüsseln im Browser

Der init()-Aufruf des Widgets akzeptiert laut Dokumentation einen unverschlüsselten apiKey in clientseitigem JavaScript. Wir raten im Produktivbetrieb davon ab: Jeder, der den Quelltext ansieht, erhält Ihren Schlüssel. Erstellen Sie die Session stattdessen mit POST /v1/sessions auf Ihrem Backend und übergeben Sie dem Widget die resultierende verification_url zur Darstellung. Das ist dieselbe Empfehlung wie beim gehosteten Ablauf, nur eingebettet statt verlinkt.

html

<div id="shieldid-verify"></div>
<!-- Exact script URL is published with your API keys; the path below is illustrative. -->
<script src="https://cdn.shieldid.ca/sdk/v1/widget.js"></script>
<script>
  // Recommended: create the session on your backend first (see API reference),
  // then pass its verification_url straight through — never a raw API key.
  TLVerify.init({
    containerId: "shieldid-verify",
    verificationUrl: "{{ session.verification_url }}", // from your backend
    theme: { accentColor: "#0B5CD8" },
  });
</script>

Mobil

Native SDKs folgen.

Derzeit gibt es kein iOS- oder Android-SDK. Öffnen Sie bis dahin die gehostete Verifizierungsseite im System-Browser Ihrer App oder in einer WebView. Es ist derselbe Ablauf wie für Antragsteller im Web, und er funktioniert schon jetzt auf jeder Plattform, auf der Ihre App läuft.

Demnächst verfügbarNative iOS- und Android-SDKs

Den richtigen Weg wählen

Drei Wege im ehrlichen Vergleich.

Beginnen Sie mit der gehosteten Seite, es sei denn, Sie haben einen konkreten Grund für die Einbettung.

Was Ihnen jeder Integrationsweg heute bietet.
Funktion	Gehostete Seite	Web-Widget	Mobile SDK
Kein SDK, kein clientseitiger Code	Ja	Nein	Demnächst verfügbar
Bleibt auf Ihrer eigenen Seite	Öffnet sich als Link	Eingebettetes iframe	Demnächst verfügbar
Abschluss-Callbacks in Ihrem Code	Return-URL + Webhook	Demnächst verfügbar	Demnächst verfügbar
Ihr Branding	In berechtigten Tarifen	In berechtigten Tarifen	Demnächst verfügbar
Funktioniert heute	Ja	Ja	Nein

Fragen

FAQ zu SDK und Widget.

Jetzt loslegen

Die gehostete Seite ist der schnellste Einstieg.

Ein API-Aufruf, ein Link, kein SDK erforderlich. Probieren Sie es noch heute mit einem Sandbox-Schlüssel aus.

Kostenlos in der Sandbox starten API-Referenz