Skip to main content

Correct Extraction

Override extracted field values with POST /v1/extractions/:id/correct — every corrected field is written at confidence 1.0 and locked as ground truth.

The Correct Extraction endpoint, POST /v1/extractions/:id/correct, overrides field values on an extraction. Pass a flat map of field name to corrected value; each field you set is written at confidence 1.0 and locked, so it is treated as ground truth and not re-derived. Use it to fix a misread value programmatically without re-running extraction.

This route is an exact alias of [PATCH /v1/extractions/:id/data](get-extraction-markdown): same request body, same write scope, same locking behavior, and the same response — the full updated extraction, so one round trip both applies and verifies the correction. It exists for clients and API gateways that prefer an explicit action-named POST over PATCH semantics; pick either route and stay consistent.

A typical workflow is to read the extraction with GET /v1/extractions/:id, spot the fields whose confidence is low or whose values fail your own validation, and post the known-good values here. Fields you do not include are left unchanged. A field name not present on the extraction is added as a new locked field rather than rejected, so exact key spelling matters — copy names from the extraction's data object.

Send values in their proper JSON types: a number sent as 1240.00 keeps the field numeric, while a quoted string stores a string. Corrections are visible immediately in every read — GET /v1/extractions/:id, the [data endpoint](get-extraction-fields) and its CSV export all reflect the corrected values, and the field appears in locked_fields with confidence 1.0.

This endpoint requires write scope; keys with only read/extract scopes receive 403. Locking is permanent — a later correction can change the value, but the field never returns to model-derived values on re-extraction.
POST/v1/extractions/:id/correct

Path parameters

id*uuidThe extraction UUID (identical to the document UUID).

Body parameters

(field_name)*anyEach key names a field to correct; the value is the corrected value. Unknown field names are added as new locked fields.

curl

curl -s -X POST https://api.talonic.com/v1/extractions/a1b2c3d4-e5f6-7890-abcd-ef1234567890/correct \
  -H "Authorization: Bearer tlnc_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{ "invoice_total": 1240.00, "currency": "EUR" }'

Response (excerpt — full updated extraction)

{
  "id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "status": "complete",
  "data": {
    "invoice_total": 1240.00,
    "currency": "EUR",
    "vendor_name": "Acme Corp"
  },
  "confidence": {
    "overall": 0.98,
    "fields": {
      "invoice_total": 1.0,
      "currency": 1.0,
      "vendor_name": 0.99
    }
  },
  "locked_fields": ["invoice_total", "currency"]
}

Errors

Error responses

401unauthorizedMissing or invalid API key.
403forbiddenThe API key lacks the write scope required to modify extraction data.
404not_foundNo extraction with this ID exists for your organization — also returned for documents your Sources IAM rules hide from this key.
429rate_limitedToo many requests. Retry after the period indicated in the Retry-After header.

Frequently asked questions

What happens to a corrected field?+
It is written at confidence 1.0 and locked, so it is treated as ground truth and not overwritten by a later re-derivation. The correction is timestamped and immediately visible on every read of the extraction, including the CSV export.
How is this different from PATCH /v1/extractions/:id/data?+
It is not — the POST route is an exact alias handled by the same code: identical body, scope requirement, locking behavior, and full-extraction response. Choose whichever verb fits your client conventions and use it consistently.
Can I correct several fields at once?+
Yes. Include multiple field-name keys in the JSON body and each one is written at confidence 1.0 and locked in the same request.
Can I add a field the extraction missed?+
Yes — a field name not present on the extraction is appended as a new locked field with your value, rather than rejected. The flip side is that a misspelled key silently creates a stray field, so copy names exactly from the extraction's data object.
Do corrections affect the normalized values?+
The corrected raw value is what subsequent reads return in data. The normalized/units maps on GET /v1/extractions/:id cover fields whose values are numeric, so keep corrected numbers as JSON numbers (unquoted) to preserve numeric treatment downstream.