Integration Approaches

After you've installed and initialized the Incode iOS SDK, choose an integration approach. This involves choosing:

• An integration path: How much UI and orchestration the SDK owns.
• An integration pattern: Where the identity verification (IDV) flow is defined and how it runs.

Choose the path first, then the pattern that fits your product.

Every entry point takes an IncdOnboardingDelegate, and every session-based entry point additionally takes an IncdOnboardingSessionConfiguration; the exception is the URL-based startFlow(url:delegate:isShortened:), which starts from a link instead.

Integration Paths

The SDK supports three integration paths, each offering a different level of control. Start with the simplest path that meets your requirements.

Path 1: Full Onboarding Flow

The SDK owns the UI from start to finish. You define the modules you want and pass them to the SDK. The SDK runs those modules in sequence and returns results through an IncdOnboardingDelegate.

This is the simplest path and the recommended starting point for most integrations.

Path 2: Split Flow

The SDK owns each module screen: the camera UI, the capture experience, and the on-device guidance. You own the order of modules and the screens between them. Use this when you need to insert your own screens between Incode steps or run only part of an identity verification journey.

Path 3: Capture-Only

The SDK owns only the capture UI. You own everything before and after capture. This path is not recommended unless your product has strict security or orchestration requirements.

See Capture-Only Mode.

Integration Patterns

The SDK supports three integration patterns. Each pattern determines where the flow is defined and how it runs.

Pattern 1: Configure Flows Locally and Run End to End

Define the flow in code with IncdOnboardingFlowConfiguration. Pass it to startOnboarding. The SDK runs every module in sequence and returns control to your app when the flow finishes.

Use this pattern with Integration Path 1: Full Onboarding Flow.

See Configure Flows Locally and Run End to End.

Pattern 2: Configure Flows Locally and Run Step by Step

Define the flow in code as one or more sections. Run each section with startOnboardingSection. Control returns to your app between sections, so you can show your own screens or logic, branch based on intermediate results, or call your back end before continuing.

Use this pattern with Integration Path 2: Split Flow.

See Configure Flows Locally and Run Step by Step.

Pattern 3: Run Flows Configured in Dashboard

Define the flow in Dashboard and start it by reference. The SDK pulls the modules and configuration from Dashboard; you don't build an IncdOnboardingFlowConfiguration locally. Activate the flow in Dashboard before starting the session. Use this when you want to update the flow without releasing a new app version.

Dashboard supports two flow types: Flows and Workflows. They behave differently depending on the integration path:

• Flows support Integration Path 1: Full Onboarding Flow only.

• Workflows support Integration Path 1: Full Onboarding Flow and Integration Path 2: Split Flow.

See Run Flows Configured in Dashboard.

Choose Your Integration Approach

What's Next