Skip to main content

Pending Reviews

List failing validation outcomes awaiting review with GET /v1/structuring/approvals/pending: the newest 100 fail rows, each naming its check and result.

The pending review queue is a cross-run feed of data quality issues: every validation check outcome whose status is fail or error, newest first. GET /v1/structuring/approvals/pending returns each such outcome with its result_id, the check's name and severity, and the failure message/details — enough to render a triage list without further fetches. Use it to drive review workflows or to monitor quality trends across all structuring runs.

Items are individual failing check outcomes, not results: a result that failed three checks contributes three rows sharing one result_id. Group by result_id for a per-record queue, drill into a record with [GET /v1/structuring/results/{id}/checks](result-checks) to see its passing outcomes too, then record a decision with [POST /v1/structuring/approvals/{id}/approve or /reject](approve-reject-result). Note the queue lists check failures regardless of severity — warning rows appear alongside critical ones, so filter client-side on severity if only hard failures matter to your reviewers.

This queue is check-driven. A result flagged by a gate purely for low confidence (a failing min_confidence rule with all checks passing) does not appear here, because it has no failing check outcome — its pending decision still exists and can still be approved by result id. Conversely, a failing warning check appears here even when no gate flagged the result.
GET/v1/structuring/approvals/pending

curl

curl -s https://api.talonic.com/v1/structuring/approvals/pending \
  -H "Authorization: Bearer tlnc_your_api_key"

Response

Response fields

dataarrayArray of failing check outcome rows (up to 100, newest first).
data[].idstringCheck outcome UUID.
data[].result_idstringUUID of the structuring result the outcome belongs to — the grouping key for per-record review.
data[].check_idstringUUID of the check that failed.
data[].statusstringfail (the data violated the rule) or error (the check evaluation crashed).
data[].messagestring | nullHuman-readable failure explanation.
data[].detailsobject | nullStructured failure detail for some check types.
data[].created_atstringISO 8601 evaluation timestamp.
data[].check_namestringName of the failing check.
data[].severitystringSeverity of the failing check (warning, error, critical).

Response

{
  "data": [
    {
      "id": "d4e5f6a7-b8c9-0123-defa-234567890123",
      "result_id": "9c2f6a1e-3b7d-4c58-9e21-8f4a5d6b7c80",
      "check_id": "5fee4bba-8380-44b8-9780-5e4548424b3c",
      "status": "fail",
      "message": "Field \"total_amount\" value 1500000 is out of range [0, 1000000]",
      "details": null,
      "created_at": "2026-08-29T11:41:12.020Z",
      "check_name": "Total amount range",
      "severity": "error"
    }
  ]
}

Errors

Error responses

401unauthorizedMissing or invalid API key.
429rate_limitedToo many requests. Retry after the period indicated in the Retry-After header.

Each row carries enough context to route work without joins: check_name and severity identify the rule and its weight, message explains the failure in plain language, and status distinguishes real data violations (fail) from broken check configurations (error). A spike of error rows is an operator signal — it usually means a check's config no longer matches the schema (a renamed field, an invalid regex) — and fixing the check stops the noise at the source.

The queue is capped at the newest 100 rows with no cursor, so at high flag rates treat it as a work-stealing feed rather than a complete backlog: poll, action the visible items, and older entries surface as the newest ones are resolved. If the queue grows faster than reviewers drain it, tighten the checks that generate noise (or drop their severity out of your gate rule's scope) rather than paging harder — a persistent 100-deep queue is a signal that gating thresholds and data quality have drifted apart.

Frequently asked questions

Can a single result appear multiple times in the queue?+
Yes. Each failing check outcome is its own row, so a result that failed three checks appears three times with the same result_id. Group by result_id when building a per-record review UI; approving or rejecting acts on the result, not on individual rows.
How do I clear the pending review queue?+
Record decisions via POST /v1/structuring/approvals/{resultId}/approve or /reject for each flagged result. The queue itself lists the newest 100 failing outcomes ordered by created_at descending, so resolving current items lets older ones surface on subsequent calls.
Does this endpoint support pagination?+
No. It returns the newest 100 failing check outcomes with no cursor or offset parameters. For a complete historical export of check outcomes, walk your results via the Jobs API and read each result's outcomes individually.
Why is a low-confidence record missing from this queue?+
Because the queue is built from failing check outcomes, and confidence is enforced by gate rules, not checks. A record held only by a min_confidence rule has a pending gate decision but no failing check row. Track those through the gate's decisions and your run results rather than this feed.

Related

Approve / Reject a Result
Result Check Outcomes
Manage Gate Rules
List Checks
List Gates