Skip to content

Configure a key

Every verification takes its settings from the key that created it, as they were at that moment. You change them in the operator console: API keys → the key → Edit key. A change applies to verifications created afterwards; running ones keep what they started with.

The steps the person goes through, in this order. Click the modules in the order you want them; the number on each shows its position, and a second click removes it. An empty flow uses the default: document, then liveness.

ModuleWhat the person doesWhat you get
documentPhotographs a passport, ID card, residence permit or driving licence (both sides where needed).Name, date of birth, nationality, document number and expiry, read from the document and cross-checked.
livenessTakes a short selfie.Proof that a live person was present, matched against the document photo.
palm_livenessMoves an open hand to a few dots on the screen (Human check).Proof that a live person, not a bot, did it — no face, no document.
termsAccepts your terms.The acceptance, with time.
form_dataFills in a short form (for example an address).The values, in the result’s contact_info.
emailConfirms an email address with a code.The confirmed address.
phoneConfirms a phone number with a code by SMS.The confirmed number.
amlNothing: runs automatically after the other steps.Sanctions screening of the name read from the document.
nfcHolds their passport or ID card to their phone so the chip can be read.The chip’s data, authenticated by the issuing state. Available on request.
walletShares a proof from their digital identity wallet.The requested attributes, for example over 18. Needs a registration with us first.

A flow needs at least one step the person does; aml alone is not a flow. The order matters: put document before liveness so the selfie can be matched to the document photo.

You can also send a different flow with a single verification (Create a verification); the key’s flow is the default.

How long the captured images (document photos, selfie) are kept. Default 90. After that they are deleted; the verification’s outcome stays.

How long the personal data the check produced (names, dates, numbers, the result’s export) is kept. It must be at least as long as the images, and at most 3,650 days (10 years). New keys start with the same value as the images.

This is your decision: keep what your own obligations require (for example a hotel’s guest register) and no more. After the deadline the verification keeps only its outcome — GET /api/v1/verifications/{id} then answers with status and export: null.

How long the link (url) works before the verification expires without a result. Default 1 day. Expired verifications send a verification.expired webhook.

Once the person has started, a verification also expires after 24 hours without any input (reason ABANDONED). To change that window, set abandon_after_hours in the key’s raw config JSON (0 turns it off).

Leave these empty to use the platform defaults; change them only when you know why.

  • Blur threshold (quality_threshold_0_10, default 4.5): how sharp a document photo must be. A lower value accepts softer photos.
  • Face match distance (face_match_max_distance, default 0.7): how close the selfie must be to the document photo. A lower value is stricter.
  • Chip face match distance (chip_face_match_max_distance, default 0.7): the same for the photo on a document’s chip.
  • Gates (recapture_gate, blackout_gate, liveness_spoof_gate): what happens when a check finds a photographed screen, a covered document or a spoofed selfie. flag_review sends the verification to manual review; shadow only records the finding.

Hides parts of images (machine-readable zone and QR codes, the portrait, specific fields) when they are shown in the operator console. The stored images are not changed.

Where ZetaID posts this key’s webhooks. It must be HTTPS and answer within 20 seconds. Empty = no webhooks; read results with GET /api/v1/verifications/{id} instead.