Choosing which data a verification returns
Every feature in a workflow has a Returned data tab that decides which fields, images and scores Didit keeps and sends back. Here's how it works, why the IP address and the MRZ live where they do, and the side effects of switching fields off.
Open the feature in the workflow and go to its Returned data tab: every field, image and score has a switch, and what you turn off is neither stored for that step nor returned in the API and webhook payload. The IP address is under Device & IP Analysis, not ID verification, and there is no single "MRZ" switch - you control the MRZ's fields one by one.
Each step of a workflow (ID verification, liveness, face match, proof of address, database validation, device and IP analysis, AML, and so on) has a Returned data tab titled Data Minimization & Privacy. It lists every data point the step can produce, grouped (for ID verification: Identity Details, Personal Information, Document Validity, Address Information, Media Assets, Quality Scores, Chip Data), with a counter of how many are included. Whatever you leave on is stored with the session and returned in the decision; whatever you turn off is not.
This is the tool for data minimisation: keep the fields your process needs, drop the rest, and the images you never wanted to hold never reach your systems or the console.
#What switching a field off actually does
- The value is not stored on the session and not returned by the decision endpoint or the
status.updatedwebhook for that feature. - The console renders the session from the same data, so a switched-off image is missing there too. If you turned off "Document image" or "Portrait image", the ID preview in the session view disappears - that is the setting, not a broken session.
- Fields marked Always cannot be switched off: they are the ones the decision itself depends on.
- It applies to sessions created after you save and republish. Existing sessions keep what they already stored.
Removing the document or selfie images makes manual review harder, because your reviewers see the extracted values but not the capture they came from. If your compliance process needs a human to look at the document, keep at least the front image for the review window and rely on retention to delete it afterwards.
#Where the fields people look for actually live
| You want | Where it is |
|---|---|
| The user's IP address, country, city, VPN/proxy flag | The Device & IP Analysis feature, under IP Data and Device & Session. Add that feature to the workflow (it is in the free tier) and the decision carries an ip_analysis block with the IP address and its signals. ID verification never returns an IP |
| The MRZ of a passport or ID | ID verification returns an mrz object together with the extracted fields. There is no single switch for it: the values it carries (document number, dates, names, nationality) are the same identity and document fields listed in the tab, so you restrict them field by field. Which lines exist depends on the document, so the shape varies by country |
| Selfie and liveness images | The Liveness feature, under Media Assets: selfie image, liveness video frame, silent selfie capture |
| Face match images and score | The Face Match feature. If a workflow runs a face comparison as part of another check (for example the document-to-selfie check inside adaptive age verification), that check has its own Returned data tab |
| Chip data read by NFC | ID verification, under Chip Data |
| Registry answers from database validation | The Database Validation feature's own tab. See database validation |
#When the tab is locked
Workflows built for an age-assurance standard show "Returned data is disabled on this workflow to comply with the standard": age assurance returns only the age decision, never the underlying personal data, and the tab cannot be changed. If you need identity fields, that is a different workflow type.
#Checking what a session actually contains
Open the session in Verifications and read the per-feature report: a field that was switched off is simply absent, not shown as empty. On the API side, compare the decision payload with the workflow's Returned data tab before assuming data was lost. See how to read a verification result.
Returned data decides what is kept and sent. It does not change what the check uses to decide: liveness still analyses the video and ID verification still reads every field, even when you don't ask for them back.