Skip to main content

Update / Delete Check

Manage a validation check by UUID: PUT patches only the keys you send (config is replaced whole), DELETE soft-deletes while keeping past outcomes for audit.

/v1/structuring/checks/{id} manages a single in-pipeline validation check. Use PUT to modify its name, description, type, severity, config, sort order, or active status, and DELETE to soft-delete it. Soft-deleted checks set is_active to false and stop running against new results, but their historical check outcomes remain intact. To inspect a check's current configuration, read it from GET /v1/structuring/checks; there is no single-check GET route.

PUT is a partial update at the top level: only the keys present in the body are patched, so sending { "severity": "critical" } changes nothing else. The config object, however, is replaced wholesale, not merged — to raise a field_range max you must resend the full config including field and min. Changes take effect for the next result evaluated; outcomes already recorded are immutable and keep the configuration that produced them implicit in their expected_value/details.

DELETE is a soft-delete: the check is deactivated (is_active = false) rather than removed, and existing outcome rows referencing it are preserved. Because PUT can set is_active back to true, deletion is fully reversible — but while inactive the check is invisible in the list, so keep a record of the id.
PUT/v1/structuring/checks/{id}

Body parameters (PUT — all optional)

namestringNew check name.
descriptionstringNew description.
typestringNew check type. Changing type usually requires sending a matching new config in the same call.
severitystringNew severity label (warning, error, critical).
configobjectNew configuration. Replaces the stored config entirely — send the complete object.
is_activebooleanSet false to pause the check without deleting; set true to reactivate a soft-deleted check.
sort_orderintegerNew evaluation/display position.

curl (PUT — widen the range)

curl -s -X PUT https://api.talonic.com/v1/structuring/checks/5fee4bba-8380-44b8-9780-5e4548424b3c \
  -H "Authorization: Bearer tlnc_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{ "config": { "field": "total_amount", "min": 0, "max": 2000000 } }'

Response

Response (PUT)

{
  "id": "5fee4bba-8380-44b8-9780-5e4548424b3c",
  "user_schema_id": "36ef3a00-a4dc-4e49-af6a-66ae20f9b58a",
  "name": "Total amount range",
  "description": "Totals must be plausible",
  "type": "field_range",
  "severity": "error",
  "config": { "field": "total_amount", "min": 0, "max": 2000000 },
  "is_active": true,
  "sort_order": 0,
  "created_at": "2026-08-29T11:35:01.940Z",
  "updated_at": "2026-08-29T11:35:30.565Z",
  "links": {
    "self": "/v1/structuring/checks/5fee4bba-8380-44b8-9780-5e4548424b3c"
  }
}

Response (DELETE)

{
  "deleted": true
}

Errors

Error responses

400VALIDATION_ERRORThe id path parameter is not a valid UUID, or a body field has the wrong type.
401unauthorizedMissing or invalid API key.
404RESOURCE_NOT_FOUNDValidation check not found or does not belong to your organization.
429rate_limitedToo many requests. Retry after the period indicated in the Retry-After header.

Use PUT to tune thresholds as your data drifts — widening a field_range, adding a values entry to a lookup, or promoting a proven warning check to critical so a critical_only gate rule starts counting it. Prefer is_active: false over DELETE when you expect to re-enable the rule: both behave identically at evaluation time, but a deliberate pause reads better in an audit than a delete-and-reactivate cycle.

Updates never rewrite history: outcomes already recorded against past results keep their original verdicts, and only results produced after the update see the new configuration. If a threshold change matters for records currently sitting in the pending review queue, action those items manually via [approve or reject](approve-reject-result) — they will not clear themselves when the check that flagged them is relaxed.

Frequently asked questions

Can I reactivate a deleted check?+
Yes. Since DELETE is a soft-delete, you can use PUT on the same check id with { "is_active": true } to bring it back. The check resumes evaluating from the next result on; nothing is re-run for results produced while it was inactive.
Does updating a check re-evaluate existing results?+
No. Updates only affect future structuring results. Historical check outcomes are immutable, and items already in the pending review queue stay there until you approve or reject them.
Can I move a check to a different schema?+
No. The schema scope is fixed at creation; the PUT body does not accept user_schema_id. Create a new check under the other schema and soft-delete the old one.
Is config merged or replaced on PUT?+
Replaced. The stored config becomes exactly the object you send, so always resend the complete configuration — sending { "max": 2000000 } alone would drop the field and min keys and leave the check unable to resolve its target field.

Related

List Checks
Create Check
Result Check Outcomes
Pending Review Queue