Verifix

Integration surfaces

Choose by constraint, not by preference

All four write to the same audit trail and emit the same webhook events.

Surface

When to use it

How it works

Hosted flow

Fastest path to production. No frontend work at all.

Create a session, redirect the subject to hosted_url, handle the return URL and the webhook.

Embedded SDK

You want capture inside your own product with no visible handoff.

Create a session server-side, pass the short-lived session token to the client, mount the SDK.

Verification link

A single customer needs verifying today, by a non-technical team.

Generate the link in the console and send it. Results land in the same queue.

Server-to-server checks

You already hold the images or data and only need a verdict.

Call the standalone check endpoints directly. No session, no flow.

Client libraries

Maintained SDKs

01

Web SDK

Drop-in capture for the browser. Mount inline, open as a modal, or redirect to the hosted flow. Camera permissions, document framing, and quality feedback handled for you.

02

iOS SDK

Native Swift capture with NFC chip reading, on-device quality checks, and a themable UI that matches your app rather than a web view.

03

Android SDK

Native Kotlin capture with NFC support, camera tuning across device tiers, and graceful fallback when a chip read is unavailable.

04

React Native and Flutter

Wrappers over the native modules so cross-platform apps get the same capture quality and NFC behavior as native builds.

05

Server libraries

Typed clients for Node and TypeScript, Python, and PHP covering session creation, standalone checks, webhook signature verification, and evidence retrieval.

06

No-code plugins

Verification steps for common platforms and automation tools, so an onboarding form can require a completed session without a build.

Minimum OS versions, bundle sizes, and plugin availability are shared with the SDK download.

Web example

Mounting capture in your own page

server, create a session

import { Verifix } from "@verifix/node";

const verifix = new Verifix(process.env.VERIFIX_API_KEY!);

const session = await verifix.verifications.create(
  {
    journey: "uae_vara_retail_individual",
    subject: { type: "individual", reference: "cust_10241", country: "AE" },
  },
  { idempotencyKey: "onb_9f2a41" },
);

// Hand session.client_token to the SDK, or redirect to session.hosted_url.

client, web SDK

import { VerifixFlow } from "@verifix/web";

// The session token is minted server-side; never expose an API key here.
const flow = VerifixFlow.mount("#verifix-root", {
  sessionToken,
  locale: "en",            // "ar" for Arabic, right-to-left handled by the SDK
  theme: { accent: "#04479C" },
  onComplete: ({ verificationId, status }) => {
    // Treat this as a UI signal only. Confirm the decision server-side
    // from the webhook plus a read of /v1/verifications/{id}.
    router.navigate({ to: "/onboarding/review", search: { verificationId, status } });
  },
  onExit: (reason) => analytics.track("kyc_exit", { reason }),
});

The client never sees an API key. Your server creates the session and mints a short-lived token scoped to that session only.

Never trust the client callback as the decision. Treat onComplete as a navigation signal, and confirm the outcome from the webhook plus an authenticated read.

Arabic and EnglishRight-to-left layoutsThemableAccessibility labelsOffline capture retry

Four ways in, all producing the same decision object