Incode provides five approaches for integrating identity verification into web environments. Each approach offers a different balance between implementation simplicity and customization depth.
Choosing an approach
Flows / Workflows: This is the starting point for most integrations. They require no front-end code and run entirely on Incode-managed infrastructure. Your backend starts a session, and you share or redirect users to the resulting URL. This approach is well-suited to teams that want to get live quickly, and to any integration where you don’t need to customize every aspect of the verification UI.
iFrame: This embeds the Incode-hosted flow within your own web page, keeping users on your domain throughout. It requires a backend and a small amount of front-end code. Choose iFrame if you want the verification experience to feel seamless within your site.
Redirect URL: Redirect URL covers two sub-patterns. Both require a backend.
- Redirect only sends the user to the Incode-hosted flow and retrieves results server-side via webhook or API. The frontend doesn't handle a return.
- Redirect and Back sends the user to the flow and receives them back in your app on completion, where the frontend uses a stored session reference to trigger result fetching.
Choose Redirect URL if sending users to a separate page for verification is acceptable.
WebViews: This option applies when your integration point is a mobile app that loads web content in an embedded browser. WebView support follows the same model as Flows and Workflows: Incode hosts the verification UI, but requires specific configuration in your native app to ensure browser APIs and hardware permissions are available.
Web SDK: This is the highest-effort option and provides the most control. Your web application hosts the verification UI directly, using Incode’s JavaScript SDK to manage the onboarding flow. This approach is suited to teams with dedicated front-end developers who need custom flow logic or full UI control.
At a glance
| Flows / Workflows | iFrame | Redirect URL | WebViews | Web SDK | |
|---|---|---|---|---|---|
| Front-end code required | No | Minimal | Minimal | Minimal | Yes |
| Backend required | Recommended | Yes | Yes | Yes | Yes |
| Hosted by | Incode | Incode | Incode | Incode | You |
| User stays on your domain | No | Yes | No | No | Yes |
| Custom UI control | No | No | No | No | Yes |
Before you Begin
The Flows/Workflows, iFrame, and Redirect URL integration methods all share the same Dashboard setup steps. Complete these before starting any of those integrations.
1. Create a Workflow
All three integration methods require a configured Workflow in Dashboard. If you haven't created one yet, see Workflows for instructions. Make a note of your Workflow ID; you'll need it when starting sessions via the API.
2. Add the Data Sharing Consent module
The Combined Consent (Data Sharing Consent) module is required in all Workflows. Add it to your Workflow in the Workflow Designer before publishing. See Combined Consent for details.
3. Enable redirect desktop to mobile (recommended)
To reduce fraud and improve conversion, enable Redirect desktop attempts to mobile in your Workflow settings. This redirects users who open the verification flow on a desktop to complete it on their mobile device instead. In Dashboard, open your Workflow, click Settings, and enable the toggle.
See Workflows for the full settings reference.
4. Set a Redirect URL in the Workflow (Redirect URL Only)
If you are implementing the Redirect and Back sub-pattern, set the Redirect URL field in your Workflow settings to the return URL in your application (for example, https://yourapp.com/verification-complete). This is what Incode uses to send the user back to your app after verification.
This field is optional for Redirect only, iFrame, and Flows/Workflows integrations — but can be useful to present a branded completion screen.
5. Obtain your API credentials
You'll need your API URL and API key to call the Incode Omni API from your backend. These are provided by Incode. Keep them server-side and never expose them in client-side code.