Get / Update / Delete Gate

Manage a review gate by UUID: GET returns the gate with its active rules, PUT patches only the keys sent, DELETE soft-deletes without losing recorded decisions.

/v1/structuring/gates/{id} manages a single review gate. GET returns the gate with its active rules embedded — the same shape as the list route, for one gate. PUT applies a partial update to gate properties (name, on_approve, on_flag, auto_approve_after_hours, destination_id, is_active); the schema scope is fixed at creation. DELETE soft-deletes the gate by setting is_active to false.

PUT patches only the keys you send, and rule management is deliberately not part of it: rules are attached and removed through their own routes (POST /v1/structuring/gates/{id}/rules, DELETE .../rules/{ruleId}), so a gate update can never accidentally drop thresholds. A PUT response echoes the gate but with an empty rules array — re-fetch with GET when you need the gate together with its current rule set.

The most useful PUT lever in day-to-day operation is is_active. Setting it false pauses the gate — new results for the schema stop being evaluated by it (and, if it is the only gate, record approval status none) — while everything the gate already queued stays actionable. Setting it back true resumes evaluation from the next result. This makes incident response cheap: pause the gate, drain the queue, resume.

curl -s https://api.talonic.com/v1/structuring/gates/4014c518-7f75-425c-bf67-3052464b95a0 \
  -H "Authorization: Bearer tlnc_your_api_key"

Response

{
  "id": "4014c518-7f75-425c-bf67-3052464b95a0",
  "name": "Finance approval gate",
  "user_schema_id": "36ef3a00-a4dc-4e49-af6a-66ae20f9b58a",
  "destination_id": null,
  "on_approve": "export",
  "on_flag": "queue",
  "auto_approve_after_hours": 24,
  "is_active": true,
  "rules": [
    {
      "id": "285aae61-8378-49e2-926a-ac54e4e54853",
      "name": "Row confidence at least 0.85",
      "type": "min_confidence",
      "config": { "min": 0.85 },
      "sort_order": 0
    }
  ],
  "created_at": "2026-08-29T11:35:09.040Z",
  "updated_at": "2026-08-29T11:35:09.040Z",
  "links": {
    "self": "/v1/structuring/gates/4014c518-7f75-425c-bf67-3052464b95a0",
    "rules": "/v1/structuring/gates/4014c518-7f75-425c-bf67-3052464b95a0/rules"
  }
}

{
  "deleted": true
}

Errors

DELETE soft-deletes the gate — pending decisions already recorded by it remain and can still be approved or rejected via [POST /v1/structuring/approvals/{id}/approve](approve-reject-result) with this gate's gate_id, so draining an old gate's queue after retiring it is fully supported. Because DELETE is just is_active: false, a later PUT with { "is_active": true } restores the gate with all its rules intact.