We have an external IDV provider. There is no CoinCover-supplied identity SDK. You install our Identity SDK in your wallet app and pass it the inquiry ID CoinCover gives you.
How the pieces fit together
1
Your backend asks CoinCover for an inquiry
Call
POST /v1/verification/start with the customer’s identifier. CoinCover creates the inquiry with the identity provider and returns a verification_id — that’s the Identity inquiry ID.2
Your wallet UI mounts the identity SDK
Hand the
verification_id to your front end and use it to initialise Identity’s SDK. The SDK takes over the screen and runs the verification flow on the customer’s device.3
The customer completes verification
Facial liveness, document checks, and the rest of the verification stack run inside the Identity SDK. Our identity provider reports the outcome back to CoinCover.
4
CoinCover emits a webhook
Your backend receives
inquiry.approved, inquiry.declined, or one of the other inquiry events. Drive your business logic from this webhook, not from the Identity SDK’s UI events.What we provide vs our identity provider
You only contract with CoinCover. Identity provider sits behind the scenes — billing, commercial terms, and provisioning are all managed through CoinCover.
Source of truth for state
The Identity SDK fires UI events as the customer moves through the verification screens — these are designed for your wallet’s screen transitions, progress indicators, and animations. They’re not the source of truth for business state. If a customer closes the browser mid-flow, those events stop firing. CoinCover’s webhook stream is what tells you authoritatively whether the verification approved, declined, or expired. Build your release-the-recovery logic on the webhook, not the SDK event.Branding and white-labelling
The Identity SDK supports white-labelling — colours, copy, logo placement — within the verification screens themselves. Configuration is done at the inquiry-template level inside Identity provider; CoinCover provisions a template per partner that you can customise. Talk to your account manager to set this up before you start integration testing. The handoff to the Identity provider feels like a step inside your wallet rather than a detour to a third party. From the customer’s perspective, the verification provider is described abstractly — they don’t need to know which IDV provider sits behind the scenes.Testing
In sandbox, you can drive verification outcomes with thex-override-status header. The Identity SDK still mounts and renders, but the inquiry resolves to whatever outcome you specify so you can exercise the approve, decline, expire, and review paths without real customers.
What’s next
Integration guide
The full backup and recovery flow.
Testing & sandbox
Driving verification outcomes for development.
API reference
Every endpoint, request, and response.