Skip to main content
Managed review decisions are separate from technical extraction status. A pending document can receive one final decision: approval, rejection, or expiry.
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.

​
Choose the document workflow

review_decision_managed is the persisted document snapshot. False or absent preserves legacy approval, result editing, reapproval, and reflagging through existing endpoints. True uses immutable managed decisions. Enabling a project does not convert historical or already-unmanaged documents. There is no automatic backfill enrollment. The state table and terminal protections below apply only to managed documents. Historical legacy_reviewed on an unmanaged document does not impose managed read-only behavior.

​
Opt in only the adopting integration

An adopting robot sends review_contract="decisions_v1" in each new extraction request. Batch requests use extraction_request.review_contract. This explicit request field, project activation, and trusted reviewer/API-key-owner access are all prerequisites. Omitted or "legacy" requests keep the old workflow even in the same enabled project with the same API-key owner. Existing web extraction calls remain legacy. A later opt-in request or reflag never changes an existing document snapshot. Verify the response snapshot before choosing the managed decision flow. See request examples.

​
Review in the web app

  1. Open Review and select a pending document.
  2. Correct extracted fields and choose Save & Mark as Reviewed to approve it.
  3. If Reject is available, select it and choose a reason: Wrong document, Duplicate document, Out of scope, or Other.
  4. Add a comment if the reason is Other. Comments accept up to 2000 characters.
  5. Select Reject document, or select Cancel to return without a decision.
A rejected document leaves the pending queue and remains in History. History shows its decision state, actor identity, time, reason, and comment. Managed terminal documents are read-only. Unmanaged documents keep their existing approval/editor behavior. Rejection does not delete the document or refund credits. Documind records the decision; your connected process reads it and performs its own cancellation.

​
Integration state contract

Managed approved, rejected, expired, and legacy-reviewed records cannot be reopened or overwritten. A new processing attempt requires a new document identity. needs_review and is_reviewed remain for compatibility. Rejected and expired records keep needs_review=true and is_reviewed=false. Use review_status=pending to query the pending queue. For managed documents, do not infer approval from these booleans, the presence of results, a missing record, or a polling timeout.

​
Read and decide through the API

Reads require extractions:read. Decisions require extractions:write and access to the document’s organization and project. Send X-Project-ID when your integration uses an active project. Use the same caller, project, payload, and UUID idempotency key when retrying an uncertain request.

​
Historical records

Migration keeps historical records unmanaged. Review metadata may label previously reviewed records legacy_reviewed; it does not create a new approval event or remove legacy editing/reapproval. Unmanaged historical records are not eligible for managed expiry. Managed expiry uses the recorded UTC review_requested_at, not mutable updated_at.