Document AI: extract the fields you define from any document

Identity documents are easy. There are roughly 14,000 of them in the world, they have fixed layouts, and a good OCR engine reads them without being told anything. The documents that actually hold up an onboarding are the other ones: a Mexican constancia de situación fiscal, a Venezuelan RIF, a Spanish escritura de constitución, an Indian bank statement, a UK payslip, a source-of-wealth letter written by somebody's accountant. No two look alike, and no template covers them.

The usual answer is a human. Someone opens the PDF, reads the number, types it into a form, and moves on — a few hundred times a week. Document AI is the answer that is not a human.

Key takeaways

• You configure up to three documents per workflow, and for each one you define the exact fields you want extracted — name, type (text, number, date), an extraction instruction, and whether it is required.
• A vision-language model reads each document against a schema built from your field definitions and returns typed values — numbers as numbers, dates as YYYY-MM-DD.
• PDF and EXIF forensics run on every upload to detect manipulation.
• Extracted fields can be cross-referenced against other steps — the account holder name on a bank statement against the name on the verified ID, for example — and against custom rules you write.
• $0.20 per document. There is also a standalone API if you already hold the file and want no hosted UI at all.

What Document AI does

You describe a document once. You give it an on-screen title and description, which are automatically translated into every verification language, and you list the data points to read. Each field gets a key, a human name, an instruction telling the model what to look for, a type, and a required flag.

The user uploads a PDF or an image. Didit renders it, runs the extraction against your schema, applies forensics, then applies your rules. The result is a per-document status that rolls up into the feature status, with Declined beating In Review beating Approved.

Why it matters

Three things break in onboarding that a fixed-template OCR cannot fix.

The document has no template. A proof of funds is whatever the customer's bank chose to print. A source-of-wealth letter is prose. The only thing that generalises is a model that reads for meaning rather than for position.

The data has to agree with the rest of the session. Extracting "J. Smith" from a payslip is worth very little on its own. Extracting it and comparing it against the full name on the verified identity document is a control. Document AI does the comparison and lets you decide what happens when it fails.

The document might be edited. A payslip with a different number pasted over the original is the oldest trick in lending. Forensic checks on the PDF structure and image EXIF run on every upload and can decline, review, or pass depending on the action you configure.

Technical details

If the file is already on your server, one request does the whole thing:

curl -X POST https://verification.didit.me/v3/document-ai/ \
  -H "x-api-key: $DIDIT_API_KEY" \
  -F "document=@payslip.pdf" \
  -F 'fields=[{"key":"account_holder","name":"Account holder","instruction":"Full name of the employee","type":"text","required":true,"is_full_name":true},{"key":"net_pay","name":"Net pay","instruction":"Net amount paid this period","type":"number","required":true},{"key":"pay_date","name":"Pay date","instruction":"Date of payment","type":"date","required":true}]'

You get the extracted fields, the name match result, and a status back synchronously. No hosted flow, no session.

Inside a workflow the same configuration lives on the DOCUMENT_AI feature, and the user uploads through the hosted flow or the SDK. DOCUMENT_AI then appears in the decision features[] array, and you fetch the result from GET /v3/session/{sessionId}/decision/ or subscribe to session.status.updated.

The rules you can set

Rule	Fires when	Action
document_ai_unreadable_document_action	The file cannot be read	DECLINE · REVIEW · NO_ACTION
document_ai_missing_required_fields_action	A required field is absent	DECLINE · REVIEW · NO_ACTION
document_ai_document_tampering_action	Forensics detect manipulation	DECLINE · REVIEW · NO_ACTION
document_ai_name_mismatch_action	The name field scores below threshold	DECLINE · REVIEW · NO_ACTION
document_ai_unsupported_file_action	The file type is not accepted	DECLINE · REVIEW · NO_ACTION
document_ai_max_attempts_exceeded_action	The user exhausts retries	DECLINE · REVIEW · NO_ACTION

Plus document_ai_name_match_score_threshold from 0 to 100 and document_ai_max_retry_attempts from 2 to 5.

Cross-referencing other steps

Custom status_rules[] reference an extracted field as document_ai. and can compare it against another step's output using value_type: "field". So document_ai.account_holder equals kyc.full_name is a rule you write, not a feature you wait for.

On a person workflow, a field marked is_full_name is compared automatically against the verified identity. On a business workflow, it is compared against the registry-matched company name.

Use cases

Lending and BNPL. Payslips and bank statements, with net pay extracted as a number your underwriting rules can act on, and tamper detection on every upload.

Crypto and high-value onboarding. Proof of funds and source-of-wealth letters, cross-checked against the verified identity.

Business onboarding in Latin America. Constancia de situación fiscal, RIF, contrato social, certificado de existencia. Documents whose format is set by a tax authority and changes without notice, read by instruction rather than by template.

Regulated professional services. Engagement letters and trust deeds, where the name on the document has to match the person who signed the session.

How to integrate with Didit

1. Open the workflow builder and add the Document AI feature.
2. Define your documents and their fields. Start from a template or build from scratch.
3. Set the basic rules and the name match threshold.
4. Add any custom status rules that cross-reference other steps.
5. Create sessions with POST /v3/session/ and read the decision, or call POST /v3/document-ai/ directly if you already hold the file.

Frequently asked questions

How many documents can I configure?

Up to three per workflow, each with its own field list, title and description.

What file types work?

PDF and images. Anything else triggers document_ai_unsupported_file_action.

Does it handle documents in other languages?

Yes. The titles and descriptions you write are auto-translated into every verification language, and extraction is instruction-driven rather than language-locked.

What does it cost?

$0.20 per document, whether through the workflow or the standalone API. The first 500 per month are free, as with every Didit feature.

Can I use it without any identity verification?

Yes. POST /v3/document-ai/ is a standalone server-to-server call. No session, no hosted UI, no identity step required.

Ready to get started?

Read the Document AI documentation, the standalone API reference, check the pricing, and start free.