Incode's Digital IDs capability lets you accept and verify government-issued digital identity credentials in any Incode flow. Digital IDs include mobile driver's licenses (mDLs), national eIDs, and government ID apps.
Digital IDs do not replace the rest of Incode's identity stack. They feed into it. Each digital ID session can still run liveness, deepfake detection, TrustGraph signal lookup, and risk scoring on top.
Supported regions
United States
Mobile driver's licenses (mDLs) from Apple Wallet, Google Wallet, and Samsung Wallet.
Europe
More than 20 national identity schemes, including MitID, BankID, itsme, SPID, and Smart-ID.
Asia
Singpass, DigiLocker, and UAE Pass.
Integration paths
Digital IDs can be integrated through three surfaces. All three require your Incode Representative to enable the Digital IDs feature for your organization first.
| Path | Where it lives | Configuration |
|---|---|---|
| Dashboard (Web Flows and Workflows) | Hosted onboarding app | ID Capture module in each Workflow; no code changes |
| SDK (mobile, web) | Your app | verificationOptions.methods in the SDK, plus Dashboard configuration |
| Server API | Your backend | Direct API endpoints for session creation and credential exchange |
For Dashboard configuration steps, see ID Capture module configuration.
For the Web SDK headless integration, see Digital ID Wallet Verification and the renderWallet API reference.
Selective disclosure
Unlike physical document capture, digital ID presentation is attribute-by-attribute. The wallet or scheme only releases the fields you explicitly request. Anything not requested never leaves the user's device.
Requested attributes are configured per flow in the Dashboard. Customers do not pass requested fields directly from the browser or SDK at runtime. This keeps every request aligned with the approved flow configuration.
When no custom attribute set is configured, Incode applies the default set for the enabled method.
Observability
Every digital ID session logs:
- The method presented
- The verification outcome, including success or fail reason
- Whether a fallback was triggered, for example when a credential is missing and the user falls back to physical document capture
- The flow ID, session ID, and device metadata
These fields are available in session results and downstream analytics. See the per-region pages for method-specific attribute sets.
Common integration notes
- Device capability detection. The iOS SDK checks entitlements and wallet contents before offering a method, so users do not reach a dead end on unsupported devices.
- Chrome on iOS. Digital IDs are not supported because of an Apple restriction. The SDK hides the option.
- Desktop. Not all credential types are available on desktop. See the per-region pages for details.
- Selective disclosure. Incode requests only the attributes required by your flow configuration. You control the minimum data set.
Provider registration
Certain credential types require you to register as a relying party with the scheme operator. Incode Support guides you through this process and, where applicable, completes the registration on your behalf. Contact your Incode Representative to get started.
Retrieving results
All digital ID methods return attributes via GET /omni/get/ocr-data/v2 under the ocrData object. Two fields identify the credential source on every digital ID session:
documentSubmissionMethodis alwaysIMPORTED_CREDENTIALcredentialsProvideridentifies the specific method (for example,apple_wallet,mitid,singpass)
Portrait photos, where available, are retrieved via /omni/get/images.