Skip to main content

Reject Diff

Reject a pending schema graph diff to flag an ontology change as incorrect or unwanted. Sets review_status to rejected for audit. Requires write scope.

Reject a schema graph diff to flag the structural change between two class versions as incorrect or unwanted. Rejection sets the diff's review_status to rejected and records who decided and when, so noisy or wrong field discoveries stay visible in the audit history as disputed changes.

Like approval, rejection is a review verdict, not a structural rollback: the versions the diff connects remain readable in the class's history. Use rejection to mark discoveries you consider extraction noise, for example a spurious field that appeared from a mis-OCRed batch, so the record shows the change was reviewed and disputed.

POST/v1/schema-graph/diffs/{id}/reject

curl

curl -s -X POST https://api.talonic.com/v1/schema-graph/diffs/diff-uuid-1/reject \
  -H "Authorization: Bearer tlnc_your_api_key"

Response

Response fields

idstringDiff UUID.
review_statusstringAlways `rejected` on success.

Response

{
  "id": "diff-uuid-1",
  "review_status": "rejected"
}

Errors

Error responses

401unauthorizedMissing or invalid API key.
404not_foundNo diff with this ID exists for your organization.
429rate_limitedToo many requests. Retry after the period indicated in the Retry-After header.
Rejected diffs are retained, not deleted. They appear with review_status: "rejected" when listing diffs, so the audit trail always shows which ontology changes a reviewer disputed.

Frequently asked questions

Does rejecting a diff undo the change?+
No. The versions the diff connects already exist and remain in the class history. Rejection records a human verdict that the change is disputed; it does not roll the class back.
Are rejected diffs kept?+
Yes. Rejected diffs are retained for audit and appear with `review_status: "rejected"` when listing diffs, together with who reviewed them and when.
When should I reject instead of approve?+
Reject when the recorded change reflects extraction noise or an incorrect discovery, such as a spurious field from a badly scanned batch. The rejected verdict marks the change as disputed in the ontology audit trail.