Skip to main content
document_subtype on the ID verification report identifies the specific document variant Didit recognized — for example a Queensland driver’s licence versus a generic driver’s licence, or a US Commercial Driver’s License versus a standard one. This page enumerates every value the field can return.
Your own workflow only accepts a subset of these — whatever you selected in the workflow’s document-settings step. Retrieve the exact accepted list for your workflow with the Management API’s workflow-retrieve endpoint (documents_allowed on the OCR node) rather than assuming every value below is enabled for you.

​
Naming pattern

Every document_subtype value is one of two shapes:
  • Bare category — {CATEGORY}, for documents Didit does not need to distinguish by region (most passports, most national IDs), for example PASSPORT_GENERIC, ID_CARD_GENERIC.
  • Region-prefixed — {REGION}_{CATEGORY}, for documents whose format or classification genuinely differs by state, province, or territory, for example QUEENSLAND_DRIVER_LICENSE_GENERIC (Australia) or CALIFORNIA_COMMERCIAL_DL (United States). The region prefix is the issuing state/province name, upper-cased with spaces replaced by underscores.
A document only gets a region-prefixed subtype when Didit’s document registry carries a distinct, separately classified variant for that region. The absence of a region-prefixed variant does not mean the document type doesn’t exist in that region — it means Didit currently reports it under the country-level bare category instead (see the CDL caveat below for a concrete example).

​
All subtype values

The table below is the full enumeration of document_subtype values the report can return, grouped by the document_type family. It already includes the region-prefixed variants — for example both DRIVER_LICENSE_GENERIC (most countries) and CALIFORNIA_DRIVER_LICENSE_GENERIC appear as distinct rows under Driver’s License. A bare-category code is not unique to one country — it’s shared by every country whose registry entry for that document has no region-specific variant. ID_CARD_GENERIC, for instance, covers national ID cards for roughly 170 countries. Only look up a code by its document_type grouping and (when present) its region prefix, never by assuming a code maps to a single country.

​
US driver’s licenses: standard vs. commercial (CDL)

document_type is "Driver's License" for both a standard driver’s license and a Commercial Driver’s License (CDL) — it never distinguishes them. The distinction lives entirely in document_subtype. In 48 of the 51 US states and territories Didit classifies, a CDL gets its own {STATE}_COMMERCIAL_DL subtype, distinct from that state’s {STATE}_DRIVER_LICENSE_GENERIC. Treating document_subtype ending in _COMMERCIAL_DL as “this is a CDL” is a reliable signal in those states.
Alaska, the District of Columbia, and Hawaii do not currently have a distinct CDL subtype. A CDL from one of these three jurisdictions is reported under that jurisdiction’s standard _DRIVER_LICENSE_GENERIC subtype — indistinguishable from a non-commercial license by document_subtype alone. If you need airtight CDL detection for these three jurisdictions specifically, contact us to register the missing document variants, or apply an out-of-band control (for example, requiring the driver to separately supply their CDL/DOT number for verification).

​
extra_fields.dl_categories is not a reliable CDL signal

Some US licenses also produce extra_fields.dl_categories — a list of the class letters (A, B, C, …) printed on the card, read via OCR. Do not use this as your CDL signal. Today this field is populated for only a small minority of US driver’s license configurations, class-letter meanings vary by state and are not normalized against a commercial/non-commercial semantic, and endorsement or restriction codes (which is where “commercial” is actually marked on many licenses) are not currently exposed on the report at all. document_subtype is the only structured, reliable signal for the standard-vs-commercial distinction today.

​
Staying in sync

New document_type families are announced in the monthly changelog when they ship. document_subtype additions — a new region variant of an existing document type, for example — are not currently announced individually; Didit’s document registry grows continuously as new document formats are onboarded. There is no version number on the webhook payload for this list. If your integration needs to detect a subtype it has never seen before rather than assuming the set is fixed, treat any document_subtype value your code doesn’t recognize as “unclassified, review manually” rather than erroring, and periodically re-check this page or your workflow’s accepted-subtype list via the Management API.