---
title: "Correct A Line"
method: POST
path: "/v1/jobs/{job_id}/corrections"
tags: ["Async Job Status & Results"]
---

# Correct A Line

`POST /v1/jobs/{job_id}/corrections`

## Request

- Base URL: `https://api.vectelos.com` (the document declares no server; this is the origin it was published from)
- URL: `https://api.vectelos.com/v1/jobs/{job_id}/corrections`
- Auth: none declared

Apply a reader's classification to one line, and recompute from it.

WHY THIS IS JOB-SCOPED AND SERVER-SIDE. The PDF is rendered from the STORED
report, so a correction applied only in the browser would leave the download
-- the artefact that actually goes to a broker -- still carrying the code the
reader has just told us is wrong. Recomputing here fixes the table, a later
poll, and the PDF in one write.

The client sends a CODE, never a computed line. Everything else is derived
from the schedule on this side, so a correction cannot be used to write
arbitrary duty figures into a report that carries our name.

WHAT IT DOES NOT DO. It does not decide the reader is right. The line is
stamped `reader_supplied`, carries no confidence score, and is marked
wherever it is displayed or printed. We recompute arithmetic on their
assertion; we do not adopt it.

## Path parameters

- `job_id` string, required

## Headers

- `authorization` string, nullable: Bearer <JWT session token>

## Cookies

- `vx_session` string, nullable

## Request body

- LineCorrection: A reviewer's edit to one line. Every field except item_index is optional; whatever is omitted keeps its current value. The reviewer owns the result — the line is stamped reader-supplied and marked as theirs on the PDF, so the old 'we only accept a CODE and derive everything from the schedule' guard is relaxed on purpose (the owner asked for full manual control and understands that changing the HTS/rate is their assertion, not ours). THE CAPS BELOW MUST NOT BE TIGHTER THAN WHAT THE ANALYZER EMITS. The editor pre-fills every field from the stored line, so a cap below the analyzer's own output makes "open the pencil and press save" fail on a line the reviewer never even changed. That is what happened: `description` was capped at 500 while `AnalyzedLineItem.description` is unbounded, so a long extracted description 422'd on a no-op save. Caps are kept (unbounded input reaches the PDF renderer) but sized above anything the pipeline produces.
  - `item_index` integer, required: Which line the reviewer is editing
  - `recompute_from_schedule` boolean: Set by the clarification picker, where the reader CHOSE a tariff line rather than asserting a rate: recompute duty and trade remedies from the published schedule for `hts_code`. Default false keeps the settled contract that a bare `hts_code` is a LABEL and does not touch duty. Ignored when `tariff_rate_pct` is supplied -- an explicit rate is always the reviewer's assertion and always wins.
  - `hts_code` string, nullable: HTS code the reviewer assigns (a label; their rate governs the duty)
  - `description` string, nullable: Reviewer's amended description / note
  - `quantity` number, nullable
  - `total_value_usd` number, nullable: Reviewer's customs value for the line
  - `tariff_rate_pct` number, nullable: Ad-valorem rate the reviewer applies; duty = value × rate
  - `quantity_unit` string, nullable: Unit of the quantity on this line (kg, each, liter, pr, doz, bbl...). Supplied for a specific or compound rate whose duty could not be computed because the invoice did not state one. The published rate still governs; this does not override it.

## Response `200`

Successful Response

- unknown

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/vectelos/apis/vectelos-api.md) · [All operations](https://skmtc.dev/vectelos/apis/vectelos-api/llms.txt) · [OpenAPI document](https://skmtc.dev/vectelos/apis/vectelos-api/revisions/8e68c96f24fa?raw)