Developer guide
The Developer Guide provides comprehensive instructions and best practices for integrating with our platform.
Identomat is a service designed to verify human identity and liveness over the Internet. This guide assumes that the integrating organization (hereafter referred to as "the company") operates a web server (referred to as "the company server") at example.com and possesses a company_key. The company_key is a credential used to securely communicate between the company server and the Identomat server (widget.identomat.com).
For enhanced security, companies can optionally implement HMAC authorization. In this case, a secret_key is used to generate and validate HMAC signatures for secure communication.
Procedure
The integration procedure consists of three main steps:
Acquiring a session token
To acquire a session_token, your backend must send a request to the /begin/ endpoint with the following parameters:
company_key– Your unique company identifier.flags– A JSON object defining global settings for the verification session.steps– An array specifying the steps to include in the verification flow. Each step can have its own step-specific flags.
⚠️ The
session_tokenis valid for 15 minutes by default.
Endpoint:
POST https://widget.identomat.com/begin/Requests can be sent as:
URL query parameters
URL-encoded form data
JSON object in the request body (recommended)
Steps and Flags Structure
flags: Defines global behavior for the entire session.steps: Allows full control of the verification process, enabling you to specify which steps to include (e.g.,liveness,identity-document) and configure step-specific flags, such as"allow_face_upload": truefor thelivenessstep.
Using Configuration or custom steps
You can initiate a session in two ways:
Via predefined configuration (Recommended):
We strongly recommend using predefined configurations via the
config_idparameter. Configurations ensure consistency, simplify integration, and reduce the risk of errors. Using configurations also allows us to deprecate legacy custom step handling in the future, helping clients maintain a clean and stable integration.
Via custom steps and flags: Only use custom steps and flags if you have very specific needs that cannot be satisfied with configurations. Over time, we encourage migrating all custom flows to configurations.
Why configurations matter:
Simplifies session creation — no need to manually define steps and flags.
Reduces risk of errors in the verification flow.
Future-proof — legacy custom step handling will eventually be deprecated.
Enables Identomat to maintain, improve, and optimize flows efficiently.
Makes integration easier.
Redirecting to the Identomat Widget
To start a verification session, the company server must redirect the user’s browser to:
Replace {session_token_here} with the actual token received from the /begin/ endpoint.
Embedding in an Iframe
Alternatively, the widget can be embedded within an iframe:
⚠️ The
allow="camera"attribute is required to grant camera access.
Checking for a result
Once the verification process is completed, the result can be detected in two ways depending on how the widget was integrated:
If redirected If you used a redirect approach (not embedded in an iframe), the user will be redirected to the
return_urlspecified in the configuration or session flags. Thesession_tokenwill be appended as a query parameter:
If embedded in an iframe, the process completion can be detected using JavaScript:
✅ Ensure you verify the message
originto avoid security risks.
Quick links
Access detailed developer guides for KYC (Know Your Customer) and KYB (Know Your Business) flows. Click a card below to explore configuration, integration steps, and best practices for each verification type.
Last updated
Was this helpful?