YOK_STUDENT document type | Docufykit Docs

Use YOK_STUDENT when your integration expects a Turkish higher-education student certificate.

This document-specific path is not generic OCR. The current flow verifies authenticity first, then applies the YOK-specific extraction and decision rules.

Request shape

Pass the document type when you create the verification:

{
  "document_type": "YOK_STUDENT",
  "process_type": "async",
  "external_reference_id": "student-12345",
  "original_filename": "belge.pdf",
  "file_size_bytes": 160585
}

The same signed-upload flow still applies:

create the verification
upload the PDF to the signed URL
call upload-complete
wait for webhook delivery or fetch the verification result

What is verified

Current product behavior for YOK_STUDENT is authenticity-first:

the worker extracts QR or barcode material
the platform verifies the document through its configured authority adapter
processing short-circuits if the uploaded file does not match the verified authority bytes
structured extraction is trusted only after the authenticity checks succeed

If the uploaded file does not pass authenticity checks, do not treat the extracted data as a valid student-certificate result.

Structured data fields

The shipped schema version is 1.1.0.

Required fields in the normalized payload:

full_name
mother_name
father_name
birth_date
nationallity
registered_at
education_type
education_duration_year
status
is_active
class
program
barcode

Optional fields currently returned when available:

university_name
faculty_name
department_name
program_name

Important compatibility note:

the current payload key is spelled nationallity in the shipped schema and JSON payloads
integrations should consume the field exactly as returned today

The extractor also breaks the program path into specific subfields and derives is_active from the status text when the status is recognized.

Expected result behavior

YOK_STUDENT can currently finish as verified when all of these hold:

document authenticity is verified
structured data exists and can be decoded
schema validation passes
confidence is above the automatic verification threshold

It falls back to review_required when the YOK-specific extraction path is incomplete or unreliable.

Current YOK-specific decision outcomes:

verified_yok_student: authenticity verified and YOK data extracted successfully
yok_student_structured_data_missing: authenticity passed but no structured payload is available
yok_student_payload_invalid: the structured payload exists but cannot be decoded
yok_student_schema_invalid: decoded payload failed schema validation
yok_student_low_confidence: authenticity passed but extraction confidence is below the automatic verification threshold

General authenticity failures can still occur before those YOK-specific outcomes, for example:

source_verification_failed
authenticity_missing_qrcode
authenticity_source_missing
authenticity_hash_mismatch
authenticity_lookup_failed

Example normalized payload

{
  "full_name": "Jane Customer",
  "mother_name": "Ayse",
  "father_name": "Mehmet",
  "birth_date": "2002-04-18",
  "nationallity": "TURK",
  "registered_at": "2021-09-20",
  "education_type": "Lisans",
  "education_duration_year": 4,
  "status": "Aktif",
  "is_active": true,
  "class": "3",
  "program": "Muhendislik Fakultesi / Bilgisayar Muhendisligi",
  "university_name": "Example University",
  "faculty_name": "Muhendislik Fakultesi",
  "department_name": "Bilgisayar Muhendisligi",
  "program_name": "Bilgisayar Muhendisligi",
  "barcode": "YOKOG3REQTMB1Y9WCC"
}

Integration guidance

Persist both top-level status and reason_code.
Treat verified_yok_student as the stable machine-readable success path for this document type.
Keep review_required flows visible to operators instead of collapsing them into generic failures.
Do not assume is_active can be trusted if you ignore the returned status text.
Use separate sandbox and production apps, keys, and webhook URLs.