Signi verification — how it works (API)

ℹ️ The new version of Signi verification (including this API) will be published to production during September 2026. Until then, the calls are not available and the description may change slightly.

Signi verification is verifying the counterparty's identity before they get to the signature — remote identification for cases where you need to know who is actually signing (AML obligations, remote contracts, HR). The counterparty goes through verification according to the rules you choose; once they complete the checks, they can sign. The proposer independently reviews the result and either approves or rejects it.

Signi verification must be enabled for your workspace — without it, the API returns a 406 error. Arrange it with your contact at Signi.

Verification groups

What exactly the verified person must prove is determined by the verification group — a set of checks (components), e.g. bank identity, identity document, liveliness check (selfie), SMS, questionnaire, micropayment, or payment card. A workspace has access to Signi's system groups and, optionally, custom ones.

curl -H "x-api-key: VAS_API_KLIC" https://api.signi.com/api/v2/verifications-groups

[
    {
        "uuid": "11111111-2222-3333-4444-555555555555",
        "name": "AML ověření",
        "isSystem": true,
        "isAml": true,
        "validityPeriodDays": 365,
        "components": ["bankId", "document", "liveliness"]
    }
]

• isAml — the group is set as AML-level verification, and Signi handles the data accordingly within the data retention policy.
• validityPeriodDays — how long an approved verification remains valid; during that time it can be reused without a new run.
• You can offer the verified person 1–2 groups — they choose which path to verify through (e.g. bank identity, or document + selfie).

Two ways to create a verification

1. At a document — the most common: you attach counterparty verification to a document in progress. The counterparty cannot get to the signature until they are verified. If they already have a valid verification, it is automatically reused.
2. At a contact — verification independent of a document: you verify a contact from the address book "in advance," and the valid verification is then applied to future documents.

Verification states

You'll learn about state changes through verification webhooks or by querying the detail.

Where to go next

• Verification at a document — the main scenario: draft → attaching verification → sending
• Creating a contact verification
• Signi verification — overview