Skip to main content

Introduction

This page picks up where Introduction leaves off. There, you created a run and uploaded a document. Here you wait for the agent to finish, read what it extracted, and optionally submit feedback through a validation task from code — writing corrected values back exactly the way the Cradl AI app does when a person reviews a document. Use this when you want to feed corrections back at scale, or run the full pipeline without anyone opening the app.

When you need a validation task

A validation task is optional for a headless run. If processing succeeds and you do not want to submit feedback, read the extracted data and stop after step 4. You do not need to create a task or send a PUT with validated values. If a formatter or validator fails, a validation task is created automatically. Reuse that task when submitting feedback; do not create another one for the same run. For example, a date formatter can fail when it receives an invalid date. For a fully headless workflow that does not need validation checks, remove validators from your model. Formatter failures can still create tasks. Validation tasks can remain open without issues with limits, performance, or cost. However, open runs are excluded from Insights statistics, so leaving tasks open can skew those statistics. Validation has no expiration or time window. You can submit corrections days later.

Before you begin

You need an access token (see Introduction) and the ID of your agent. If you plan to submit feedback in steps 5–7, you also need the agent’s validation ID. The validation ID is in the agent’s resourceIds:
Take the entry starting with cradl:validation: — that is the <YOUR-VALIDATION-ID> used in steps 5 and 7.

The flow

1

Create a run

Create a run on your agent. Keep the id from the response — it is on the form <org-id>/<agent-id>/<run-id> and is the agentRunId that every later call needs.
variables is optional. It does not affect predictions — it is passed through and returned with the agent’s output.
2

Create and upload a document

Create a document attached to the run, then upload the file bytes to the fileUrl from the response.Save two more fields from that response: documentId and annotationFileUrl. You need the annotation file URL in steps 4 and 6.
The Python SDK’s create_document performs both the POST /documents call and the file upload for you, and deletes the document again if the upload fails.
3

Wait for the agent to finish

Poll the run until its status is completed or ready-for-review. A completed run has finished processing; ready-for-review means a validation task is waiting for input.
Polling is the simplest option, but not the only one. To be notified instead of polling, use a Webhook export, or configure notifications on the validation itself, which can fire when a review task is created or cancelled, or when a run fails.
4

Read what the agent extracted

There are two files to read, and they serve different purposes. Both live on the file server and are fetched with a plain GET and the same Authorization header.The run’s variables file (variablesFileUrl on the run) is the run payload — the same data your export actions receive. Values are either plain values or objects with a value key.The document’s annotation file (annotationFileUrl from step 2) holds the per-field annotations that the review UI edits. This is the file you write back in step 6.
The JavaScript SDK exposes makeFileServerGetRequest and makeFileServerPutRequest for these reads and writes.
5

Create a validation task (only when submitting feedback)

Skip steps 5–7 if you do not want to submit feedback. If a task was created automatically because a formatter or validator failed, use its taskId in step 7 and continue to step 6 without creating another task.Otherwise, create a task for your feedback. input is required — send an empty object unless you have something to put there.
The response contains a taskId on the form cradl:task:xxx and status: "ready".
6

Write the corrected annotations

Correct the annotations you read in step 4 and PUT the whole object back to the document’s annotationFileUrl as JSON. See Annotation file format below for the structure.
7

Complete the task

The annotation PUT in step 6 does not close the task. If you leave an existing task as is, it remains open. To complete it, patch the task to succeeded. Send the same annotations object as output — the file you wrote in step 6 is the working copy, while output is what the completed task carries.
The task accepts output, metadata, status, name and description on a patch.
To reject a document rather than approve it, cancel the task and say why:

Annotation file format

The annotation file is a JSON object keyed by the field IDs defined in your agent’s model.
  • Every field maps to an array. A single-value field is an array with one element, a multi-value field has one element per value, and a table field is an array of row objects keyed by column ID.
  • Each annotation has up to five keys: value, rawValue, confidence, page and id. null is allowed for all of them, so a hand-written correction can be as short as {"value": "2021-05-01"}.
  • Annotation files produced by the model also carry read-only fields such as location (four normalized numbers describing the bounding box) and source. These are dropped when the file is overwritten, so do not rely on a write preserving them.

Complete example

This example reads the extracted data by default. Set SUBMIT_FEEDBACK to True to submit feedback and apply your corrections where indicated. If a validation task already exists, set EXISTING_TASK_ID to its ID to reuse it.
The code example below has been generated by an AI. Use it as a starting point and verify correctness before using in production.