Which Shufti Integration Mode Is Right for Your Stack? API, SDK and Web Client Explained

According to Postman’s State of the API 2024 report, 43% of developers identify API integration as their most time-consuming development task. For teams adding identity verification to a regulated product, the wrong integration choice does not just slow delivery; it creates compliance gaps that are expensive to close later.

Shufti provides five distinct integration modes, each designed for a different combination of technical requirements, deployment constraints, and go-live timelines. This guide maps each mode to the scenario where it fits best, so your team can make the decision once and ship.

Why the SDK-or-API Binary Misses the Point?

Most developer-facing identity verification content frames the integration decision as a binary: SDK or API. That framing ignores three other modes that exist precisely because not every product is a backend service, and not every team has weeks of engineering runway available.

Shufti’s integration architecture is built around the real distribution of products that need verification: native mobile apps, web-based onboarding flows, no-code compliance stacks, and enterprise deployments with data sovereignty requirements. Each mode serves one of these contexts. The RESTful API is not inherently better than the Web Client; it is better for a specific kind of team building a specific kind of product.

Shufti’s Five Integration Modes

1. RESTful API

Shufti’s RESTful API gives your backend full control over the verification workflow. Your server submits a verification request, Shufti processes it, and the results are returned asynchronously via webhooks (HTTP POST payloads delivered to your endpoint once the check completes). The same API endpoint covers all Shufti products: document verification, face matching, AML screening, KYB, and more.

Use this when: you need server-to-server verification, batch processing, or tight coupling with your existing orchestration layer. Backend engineers at fintech and financial services firms typically choose this path when verification logic needs to sit inside their own user lifecycle management rather than on the client side. Technical lift is the highest of the five modes, but so is the degree of control. Over 83% of enterprise workloads rely on APIs for data communication and automation, and Shufti’s API is built to sit inside that infrastructure from day one.

2. Mobile SDKs

Shufti’s Mobile SDKs are available for Android, iOS, Flutter, React Native, and Cordova. They manage document capture, liveness detection, and facial biometrics directly on the device, passing processed results to Shufti’s verification pipeline.

Use this when: you are building a native mobile application, and biometric capture quality is a priority. Mobile SDKs access the device camera pipeline directly, which means they can detect camera injection and presentation attacks at a level that browser-based channels cannot match. This aligns with the authenticator assurance principles in NIST SP 800-63B, which recognise native device access as the strongest channel for biometric verification. The SDK handles the capture UX; your application manages the session flow.

3. Web Client (Tailored Verification Page / iFrame)

Shufti’s hosted Web Client is a pre-built verification flow that you embed in a browser session via iFrame. Shufti handles the user interface, document and biometric capture, and result delivery. You receive a webhook when the check completes, with no need to build or maintain the verification UI yourself.

Use this when: you need a web-based onboarding flow and want to avoid building and maintaining verification UI. This is typically the fastest path for web products: integration takes days rather than weeks, data handling obligations under GDPR Article 32 are managed on Shufti’s side, and no mobile SDK build is required. Technical lift sits at low to medium.

4. Journey Builder

Journey Builder is Shufti’s no-code verification flow configurator. Compliance teams and operations leads can assemble multi-step verification workflows (document check, face match, AML screening, address verification) from a visual interface, without writing a line of code.

Use this when: you need to deploy or iterate on a verification flow quickly and engineering capacity is the constraint, not technical feasibility. It is also the right choice for teams that need multiple market-specific flows: different countries, different document types, different AML watchlists, all configurable independently. The Journey Builder library includes pre-built flows covering more than 30 markets. Time to go-live: hours to a day for a first deployment.

5. On-Premises

Shufti’s On-Premises deployment runs the entire verification stack inside your own infrastructure. No verification data leaves your environment. The same RESTful API interface applies, and you retain full control over the compute layer, data residency, and audit trail.

Use this when: data sovereignty is a hard requirement. Banks and financial institutions in jurisdictions with strict data residency mandates, or enterprises under sector-specific frameworks that restrict cloud-side data transfer, use this path. Time to go-live is the longest of the five modes, but the security posture is also the highest: cloud-side data exposure is eliminated entirely.

Choosing the Right Mode: A Practical Framework

Two questions narrow the choice quickly.

• First, where does your product live? Native mobile apps point toward the Mobile SDK. Web-based products default to the Web Client or RESTful API. Teams without engineering time start at Journey Builder. Regulated enterprises with data residency requirements need On-Premises.
• Second, how much engineering time is available? If the timeline is measured in hours, Journey Builder is the realistic option. Days to a week: Web Client or API. One to two weeks: API or Mobile SDK. Open-ended enterprise deployment: On-Premises.

Teams building KYC into a financial product often start with the Web Client for the fastest compliant go-live, then migrate to the API once the core workflow is proven. A broader guide to planning that lifecycle is available in KYC Integration Strategies for Smooth and Regulatory-Compliant Onboarding.

Using Multiple Modes Together

Using more than one Shufti integration mode in a single product is common and architecturally intended. A financial services application might run the Web Client for browser-based onboarding, the Mobile SDK inside its native app, and the RESTful API for background AML re-screening, with all three connecting to the same platform, dashboard, and compliance data. For a deeper look at how the API layer functions within a broader identity verification services stack, see KYC API: What It Is, How It Works, Integration & Use Cases.