Ways to integrate: API, SDKs, and no-code links

You don't need to write code to start verifying people with Didit - use a no-code link, or bring in an SDK or the API when you want automation.

You don't need a developer to launch identity verification with Didit. There's a no-code option that takes minutes, plus API and SDK options for when you want it automated inside your own product.

#Can I use Didit without coding?

Yes. Once you've built a workflow in the console, you can generate a verification session two ways with zero code:

1. Verification link (one-time)

   Press New verification (on Home, the verifications list, or a person's profile), pick a workflow, add your own ID for the person under Vendor data, and press Create verification. Then send the link by email, copy it, or show the QR code. The Single check tab runs one check, such as AML screening, without a whole workflow.

2. Reusable link (Unilink)

   Each workflow also has one reusable link that starts a fresh session on every visit. Put it behind a button on your site, print it as a QR code for a kiosk or branch, or share it with affiliates. See reusable links.

Both skip the API and your backend entirely - the right choice for MVPs, manual review, in-person verification, or getting started before you've built anything custom.

#When you want automation

If you need the result to update your own systems automatically - not just show up in the console - you'll want the API or an SDK:

#Sending the link yourself

If you create a session through the API, Didit returns the verification URL - and delivering it is then yours to do. Sending it from your own product, with your own copy and branding, is usually the better experience anyway: the person already trusts you, and a message from an unfamiliar sender is a conversion cost.

If you need Didit to email the person instead, pass contact details when creating the session. Confirm what's supported for your setup rather than assuming, and note that the email language is a separate field from the flow language. See setting the verification language.

#Choosing between hosted, embedded, and native

If NFC matters to you, that row decides it: the chip can't be read from a browser page. See NFC chip verification.

Which embedded options are available on your plan is worth confirming with your Didit contact before you scope a project around one.

#Standalone APIs vs workflow sessions

A workflow session runs the checks together, produces one aggregate decision, and is billed per completed feature. A standalone API call runs one check on data you supply, returns just that result, and is billed per call at its own list price.

Standalone calls are the right tool for batch processing, for a capture UI you built yourself, or for a check you want to run outside an onboarding flow. They're the wrong tool if you wanted one aggregate decision for the whole flow.

#Testing before you go live

Switch the console to Sandbox with the pill under your application's name, create a sandbox API key there, and use it. Every check is mocked, nothing is billed, and you can force any outcome you want. Sandbox keeps its own data, keys, webhooks and lists, apart from Live.

testing in sandbox

#Next steps

• Set up a workflow first if you haven't: building a verification workflow
• Get results the moment they're ready: getting verification results with webhooks
• Where to find your API key: managing your API keys
• When something returns an error: API errors and what they mean

#Connecting AI tools

On Connect AI tools, select your tools and follow their setup instructions. When authorizing a connection, choose the intended organization and review the requested permissions before approving. If the account or organization is wrong, switch it before granting access.