Skip to content

Documents

A Document represents one PDF or image uploaded to a Workspace and everything Dockt learns from processing that file. The resource groups the detected document type, extracted public facts, applicable checks, issues, and final result under one ID.

A Document answers questions about the file itself. It doesn’t, by itself, answer whether a worker satisfies every requirement that applies to their situation. Use an Assessment when you need that broader answer.

Create a standalone Document with POST /v1/documents when one file can be handled independently. Your product might use this to check a document at upload time before deciding what to do next.

Create an assessment-linked Document with POST /v1/assessments/{assessmentId}/documents when the file is evidence for a worker Assessment. Dockt processes it as a Document and also makes its result available to the Assessment’s requirements and next Decision.

Don’t upload the same file through both routes for one workflow. Choose the route based on whether the result stands alone or must contribute to an Assessment.

Uploads use multipart/form-data with one file part. Files must be non-empty PDFs or images no larger than 10 MB. Declare the file’s MIME type when possible.

Document processing is asynchronous because classification, extraction, and applicable checks may continue after the upload request returns. The status field tells you whether that work is still running:

A Document has one of these statuses:

  • uploaded: Dockt accepted the upload.
  • processing: Verification is in progress.
  • completed: Processing finished and document_result is available.
  • failed: Processing couldn’t produce a result.
  • withdrawn: The Document was deleted from active use.

POST /v1/documents and assessment upload return 202 Accepted. This means Dockt stored the upload and created the Document; it doesn’t mean the file passed verification. Store the returned Document ID, then poll GET /v1/documents/{documentId} or receive a Document webhook before interpreting the result.

Treat failed and invalid differently. failed is a processing status: Dockt couldn’t produce a result. invalid is a completed result: processing succeeded and the applicable checks concluded that the file was invalid.

For a completed Document, document_result summarizes the file-level conclusion:

  • valid: The document passed applicable intrinsic checks.
  • review_required: One or more issues need review.
  • invalid: The document failed applicable intrinsic checks.

An unsupported document type completes as review_required with a type_unknown issue. Processing succeeded, but Dockt couldn’t confidently apply a supported document workflow. Ask the user for a supported document or send the file to review.

Your product should branch on document_result, then use issues, findings, and the detailed fields to explain the result. Don’t reconstruct a result by combining individual checks yourself.

The canonical Document read can include several layers of information:

  • classified_as: what kind of document Dockt detected, including its family, type, and optional variant.
  • facts: public values extracted from the file, with confidence where available. Use these as structured observations, not as replacements for the result.
  • verifications: results from checks that apply to the detected document.
  • enrichment: additional evidence-discovery checks and warnings that may provide context.
  • credential_assertions: customer-safe records of verified credentials where available.
  • issues and fraud_signals: machine-readable reasons that the file needs attention.
  • findings: actionable conclusions produced from this Document, with codes and explanations suitable for workflow and review.

Not every field is populated for every file. The detected type and applicable checks determine which details are available. Write your integration to handle empty optional collections without treating them as errors.

The classified_as.type value identifies the Document. It is not the same as an Assessment requirement’s accepted_evidence_types, which describe the purpose the evidence must serve. Dockt maps processed Documents to requirements and returns the result through each requirement’s Document ID arrays. See Document uploads and evidence for upload requirements and evidence handling.

Document enrichment is reported separately from document_result. A warning or unavailable enrichment check doesn’t automatically make an otherwise valid Document invalid. Use document_result as the top-level conclusion.

Delete a standalone Document with DELETE /v1/documents/{documentId}. For an assessment-linked Document, use DELETE /v1/assessments/{assessmentId}/documents/{documentId}.

Withdrawal removes the Document from active processing and later evaluation. Use it when a user uploaded the wrong file or the file should no longer support an active case. It doesn’t erase or change Decisions that were already created from an earlier Assessment input version.

Verify a standalone document

Document fact keys and credential assertions