SDKs
The ID verification SDK, and the zero-SDK path.
Most integrations don't need an SDK at all — the hosted page does the work. The web widget is there when you want the flow to stay inside your own page. Native mobile SDKs are next.
The zero-SDK path
The hosted page needs no SDK, on any platform.
POST /v1/sessions returns a verification_url. Send it to the applicant however your product already sends links — email, SMS, an in-app redirect, a QR code on a screen — and ShieldID handles capture, the liveness challenge and the selfie on their own phone.
- Works from a web app, a native app's system browser or WebView, an email link, or a kiosk QR code — nothing to install
- White-label branding on qualifying plans, so it doesn't look like a hand-off to a third party
- Results reach you through the return_url redirect and the signed webhook — no client-side callback wiring required
The web widget
Embed the flow in your own page.
A small script that renders the hosted verification flow inside an iframe on your page, instead of sending the applicant away from it.
What works today
- TLVerify.init({ apiKey, containerId, returnUrl, cancelUrl, webhookUrl, locale, theme }) creates a session and mounts it in an element you choose
- Runs the identical capture flow as the hosted page, inside your layout, with your accentColor and logo
- Works today for creating a session and showing the flow inline
Completion callbacks
Coming soononComplete, onCancel, onStep and automatic iframe resizing are part of the widget's interface, but nothing inside the flow triggers them yet. Don't build logic that depends on them firing — use the return URL and the webhook instead, both of which work today.
A note on API keys in the browser
The widget's own init() call is documented to accept a raw apiKey in client-side JavaScript. We don't recommend that in production: anyone who views source gets your key. Create the session on your backend with POST /v1/sessions instead, and pass the widget the resulting verification_url to render — the same recommendation as the hosted flow, just embedded instead of linked.
<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>Mobile
Native SDKs are coming.
There's no iOS or Android SDK today. Until there is, open the hosted verification page inside your app's system browser or a WebView — it's the same flow a web applicant gets, and it works now, on any platform your app runs on.
Coming soonNative iOS and Android SDKs
Choosing a path
Three ways in, honestly compared.
Start with the hosted page unless you have a specific reason to embed.
| Capability | Hosted page | Web widget | Mobile SDK |
|---|---|---|---|
| No SDK, no client-side code | Yes | No | Coming soon |
| Stays inside your own page | Opens as a link | Embedded iframe | Coming soon |
| Completion callbacks in your code | Return URL + webhook | Coming soon | Coming soon |
| Your branding | On qualifying plans | On qualifying plans | Coming soon |
| Works today | Yes | Yes | No |
Questions
SDK and widget FAQ.
Start building
The hosted page is the fastest way in.
One API call, one link, no SDK required. Try it with a sandbox key today.