Sell verification as
your own product.

# Integrate Didit for multiple clients

Integrate Didit into <my_stack> for a product serving multiple clients.
Use each client's configured application and workflow, apply their branding,
and route authenticated results through your product.

## Public module prices
- ID Verification: $0.15 per check
- Passive Liveness: $0.10 per check
- Face Match 1:1: $0.05 per check
- IP Analysis: $0.03 per check
- Full identity bundle (the four above): $0.33 per check
- AML (anti-money laundering) Screening: $0.20 per check
- Ongoing AML Monitoring: $0.07 per user per year
- Business Verification: Variable per registry check;
  person screening, document checks, and linked identity checks are billed separately
- White Label: $0.20 per check on top of the modules used
- 500 free monthly workflow checks; standalone requests are outside that allowance

Use these published costs when setting your product's client pricing.
Review commercial requirements with Didit; do not infer partner rates.

## 1. Configure client applications
Create an account at https://business.didit.me. Use separate applications
for each client and environment: live and sandbox are separate applications,
not two environments inside one application. Sandbox outcomes are simulated.
Store application keys and workflow UUIDs in your server-side configuration,
indexed by client and environment. Never expose keys to end users.
Enforce client authorization in your own product. Resource permissions do
not establish a client-specific boundary, and an application is not a
promise of isolation from every organization-level resource.

## 2. Brand the verification flow
Configure colours, typography, square and rectangular logos, corner radius,
and the login-screen option in the Style Editor. The Texts tab overrides
supported strings, one locale at a time; it does not expose arbitrary text
on every screen. Choose the completion-screen mode where needed.

For a custom domain:
- Use an unused subdomain such as verify.yourbrand.com, not a root or www. domain.
- Enable White Label on the account and grant write access to Customization.
- Add both generated CNAME records: ownership/certificate verification and routing.
- Verify ownership in the console once the records resolve.
- A custom domain prevents re-enabling the Didit login screen until removed.

Enable Workflow → Settings → Options → Include custom style for every
workflow that should use the branding. Otherwise it retains default branding.

White Label changes visual branding. Retain the required provider disclosures:
identify your company as requesting verification and Didit as powering it,
link your privacy notice and applicable terms, and link Didit's Verification
Privacy Notice and End User Terms for Identity Verification. Collect affirmative
consent where required and retain the necessary proof in your own systems.
These responsibilities also apply when you build your own verification UI.

## 3. Publish each client's workflow
Build a workflow in the Console or with
POST https://verification.didit.me/v3/workflows/.
Use a KYC (know your customer) workflow for people or a KYB (know your
business) workflow for companies. Configure the relevant checks and publish
the draft. Existing sessions retain their original workflow version.

## 4. Create the session for the correct client
Resolve the application key and workflow UUID from trusted server-side
configuration for this client and environment:

  curl -X POST https://verification.didit.me/v3/session/ \
    -H "x-api-key: <client-application-key>" \
    -H "Content-Type: application/json" \
    -d '{
      "workflow_id": "<client-workflow-uuid>",
      "vendor_data": "<client-id>:<end-user-id>"
    }'

vendor_data contains your references and is returned on session events and
decision reads. Do not assume unrelated entity or transaction events have
this same session envelope. Open the returned url or embed the hosted flow.

## 5. Receive authenticated results
Register a destination for status.updated and data.updated and store its
secret_shared_key, scoped to the client and environment in your configuration.
Verify before reading a decision or changing a client's data:
- X-Signature-V2: HMAC-SHA256 over recursively sorted, compact JSON with
  Unicode preserved. This header does not sign raw bytes.
- X-Signature: supported HMAC-SHA256 over the exact raw request bytes,
  captured before JSON middleware. The terminal example uses this variant.
- Check signature format and length before a constant-time comparison.
- Validate X-Timestamp and reject a difference greater than 300 seconds.
  Require it to match the timestamp in the authenticated payload.
- Resolve the destination secret from trusted route configuration, not from
  an unverified vendor_data value. Confirm the authenticated reference
  belongs to that client before routing the result.
- Dispatch on webhook_type, handle duplicate deliveries, and durably queue
  work before acknowledging. Return 2xx promptly, within the 5-second timeout.

Session statuses: Approved, Declined, In Review, In Progress, Not Started,
Abandoned, Expired, Kyc Expired, Resubmitted, Awaiting User. Entity and
transaction events have different status enums; do not feed them into the
session dispatcher.
Session events include session_id, status, webhook_type, created_at,
timestamp, workflow_id, workflow_version, vendor_data, metadata; decision
is present for Approved, Declined, In Review, and Abandoned.
Business sessions also include business_session_id and session_kind: "business".
For reconciliation read
GET https://verification.didit.me/v3/session/{sessionId}/decision/
using the same client's application key. Your authorized team can also
review results in the Console.

## 6. Control team permissions
Assign each member one role. Five built-in roles are available; organization
owners can create custom roles. Allowed actions differ by resource:
- sessions: read, list, create, write, delete
- users: read, list
- businesses: read, list, write
- workflows and questionnaires: read, write, create, delete
- customization: read, write
- api-keys: read, write
Use a dedicated custom role for support access. Do not grant access to all
applications merely because a support agent needs to review sessions.

## 7. Add checks and verify the integration
Edit and publish a draft of one client's workflow. New sessions use that
version; other workflows and existing sessions retain their configuration.
Review the published costs of the added checks.

1. Configure two example clients with distinct application keys, workflows,
   and webhook secrets. Test your own authorization against cross-client access.
2. Confirm sandbox and live traffic use separate applications.
3. Check each workflow's custom-style setting, domain, and required disclosures.
4. Reject malformed or invalid signatures, stale timestamps, and a reference
   that belongs to another client. Include Unicode in signature fixtures.
5. Confirm vendor_data returns unchanged on session updates and decision reads.
6. Confirm changes to one workflow affect only new sessions using that workflow.

References:
- https://docs.didit.me/console/white-label
- https://docs.didit.me/console/custom-domain
- https://docs.didit.me/console/roles-permissions
- https://docs.didit.me/console/workflows
- https://docs.didit.me/sessions-api/create-session
- https://docs.didit.me/integration/webhooks
- https://docs.didit.me/integration/sandbox-testing

Start at https://business.didit.me.