Skip to main content
Your integration owns downstream processing and cancellation. Documind provides extraction results and explicit review decisions.
Explicit review decisions require the review-state migration and a compatible backend deployment. Documentation publication does not enable the feature. Check review capabilities before integrating. For managed documents, missing or unknown review_status stops automatic processing. Projects explicitly opt in after customer integrations support terminal decisions. False or absent review_decision_managed keeps existing legacy behavior; it never enrolls a document implicitly.

​
Processing sequence

  1. Upload a document and keep its document ID with your work item.
  2. Only an adopting integration sends review_contract="decisions_v1" for a new document, or extraction_request.review_contract for batch creation. Omitted or "legacy" requests stay legacy, even in an enabled project. Inspect the persisted snapshot, then stored technical status and managed review_status.
  3. Dispatch using the state table below.
  4. For pending documents, use the safe polling example.
  5. Make downstream processing and cancellation idempotent in your integration.
Keep rejected or expired work items separate from approved output. Do not archive them as successfully processed. An API error, empty history response, or local timeout must not send raw extraction results to your downstream system.

​
Project and caller scope

Use the same authorized API key and active project when extracting, polling, and deciding. Read calls require extractions:read; decision calls require extractions:write. Send X-Project-ID when using an active project. Do not switch callers when retrying a decision with its original idempotency key.

​
Availability and customer rollout

Approval remains available while rejection and expiry are disabled. Capability values apply to the active project; they are not per-document enrollment or permission checks. Use the persisted review_decision_managed snapshot, not current project enablement, to select the workflow. Existing unmanaged work keeps legacy behavior. Confirm that each affected customer integration handles rejected and expired states before requesting enablement. A capability response does not prove downstream cancellation occurred.

​
Expiry policy

Choose a local waiting policy that fits your workflow. A local timeout does not change Documind state. If your policy requires expiry, an authorized API-key caller can submit it only after pending age is strictly greater than ten days. See decision requests. Before activation, confirm explicit per-request contract opt-in, project opt-in, integration compatibility, and explicit managed-review access for each reviewer and API-key owner. Legacy membership permissions are unchanged and do not automatically grant the new feature.