Plan your backend integration

Dockt is an API that your backend calls to verify documents or evaluate a worker case. Before you write application code, decide which workflow you need and where Dockt state fits in your system.

You don’t need to reproduce Dockt’s evaluation logic. Your backend sends inputs, stores Dockt resource IDs, and acts on the returned result.

Choose your workflow

Start with one of these workflows:

• Use a standalone Document when one uploaded file needs its own result.
• Use an Assessment when you need to evaluate one worker, their circumstances, and one or more supporting Documents together.

An Assessment is not a batch of unrelated Documents. It represents one worker case that can change as you provide context or upload evidence. Each evaluation creates an immutable Decision.

If you are still deciding, compare Documents and Assessments.

Keep Dockt behind your backend

Your application normally has three parts:

1. Your client collects worker information or a file.
2. Your backend sends the request to Dockt with a workspace credential.
3. Your backend stores the returned IDs and presents or acts on the result.

Keep API credentials, webhook secrets, and document uploads out of browser and mobile code. If a browser uploads a file to your product, send it to your backend first.

Use the backend API surface

Most verification integrations use these endpoint groups:

Goal	Endpoint group
Confirm authentication	GET /v1/auth/me
Read active configuration	/v1/features and /v1/social-compliance-packages
Verify one file	/v1/documents
Evaluate one worker case	/v1/assessments and /v1/decisions
Receive completion events	/v1/webhooks

The API reference also contains browser-session, Account, Workspace, user, and credential-administration operations. You don’t need those operations for a backend that already has a workspace credential. Use them only when your product also manages Dockt administration.

SDKs and generated clients

Dockt supports its REST API and OpenAPI JSON as the integration surface. You can call the API with your HTTP client or generate types and client code from OpenAPI.

For a generated TypeScript type file, run:

npx openapi-typescript https://api.dockt.com/openapi.json \
  --root-types \
  --root-types-no-schema-prefix \
  --output src/dockt-schema.d.ts

Pin the generated file in your repository. Review the OpenAPI diff before replacing it. This keeps a contract change from silently changing your application build.

The TypeScript backend guide uses native fetch and generated OpenAPI types. The same resource flow applies in other languages.

Store resource lineage

Store Dockt IDs beside the corresponding record in your system. At minimum, retain:

• Your own case or upload ID.
• The Dockt Workspace ID used by the integration.
• The Assessment or standalone Document ID.
• Every uploaded Document ID.
• The Decision ID and assessment_input_version your product acted on.
• The idempotency key used for each create or upload operation.
• The latest known status and the time you last reconciled it.

Don’t use a filename, worker name, or external_id as the Dockt resource identifier. Dockt IDs remain the canonical values for later API calls.

Plan for asynchronous results

Document processing and Assessment evaluation continue after the create or upload response. A 202 Accepted response confirms that Dockt accepted the work; it is not a verification result.

Use this production pattern:

1. Store the resource ID before returning success from your own backend.
2. Receive signed webhooks as the main completion signal.
3. Fetch the canonical resource after each event.
4. Run periodic API reconciliation for resources that did not receive an event.
5. Apply an application-owned deadline without converting elapsed time into a Dockt result.

The public API does not define a guaranteed completion time. Continue to treat uploaded and processing as unresolved states until Dockt returns a terminal state.

Choose the next step

• Build a typed TypeScript backend.
• Verify a standalone Document.
• Complete an Assessment.
• Test your integration.