docufykit.comVerify. Extract. Deliver.
Sign inQuickstart

Docufykit's public verification API authenticates with X-API-Key. Customer integrations should use that header on every public verification route.

This is separate from the internal admin Authorization: Bearer ... token model shown in local README examples for backoffice routes.

Public routes that require customer credentials

Use X-API-Key on these routes:

  • POST /v1/verifications
  • POST /v1/verifications/{verification_id}/upload-complete
  • GET /v1/verifications/{verification_id}

POST /v1/verifications also requires an Idempotency-Key header so retries do not create duplicate jobs.

Base URL and environment separation

  • Use the base URL assigned to your environment. For production use https://api.docufykit.com.
  • Create separate client apps for sandbox and production.
  • Use a different API key and webhook destination per environment.
  • Keep portal login credentials separate from public API credentials.

Required headers by route

Create verification

X-API-Key: <your-api-key>
Idempotency-Key: <your-stable-request-id>
Content-Type: application/json

Confirm upload completion

X-API-Key: <your-api-key>

Fetch a verification

X-API-Key: <your-api-key>

Example authenticated request

curl -X POST "https://api.docufykit.com/v1/verifications" \
  -H "X-API-Key: <your-api-key>" \
  -H "Idempotency-Key: order-2026-0001" \
  -H "Content-Type: application/json" \
  -d '{
    "document_type": "YOK_STUDENT",
    "process_type": "async",
    "external_reference_id": "student-12345",
    "original_filename": "belge.pdf",
    "file_size_bytes": 160585
  }'

Key-management guidance

  • API keys belong to a specific client app.
  • Rotate or revoke keys per app, not globally across every environment.
  • Keep keys on your backend. Do not ship them in browser code or mobile binaries.
  • Generate one stable Idempotency-Key per business request and reuse it only for safe retries of the same create call.

Next pages