set-triggers

A real response, captured from a live call to set-triggers:

{
  "lifecycle_id": "qlc_000191",
  "result": {
    "target_id": "6ab1944e7566f41b5c28e2eb",
    "target_type": "table",
    "triggers": []
  }
}

// the object you get back IS the result — there is no `.result` to read
{
  target_id: '6ab1944e7566f41b5c28e2eb',
  target_type: 'table',
  triggers: []
}

// The TS SDK names these camelCase — lifecycleId, traceId — where Python uses
// lifecycle_id and trace_id. Both are non-enumerable: readable, but omitted by
// Object.keys() and JSON.stringify(). `result.lifecycleId` here is undefined.
result.lifecycleId // 'qlc_000191'

# a dict subclass; `result` is already unwrapped
{
 "target_id": "6ab1944e7566f41b5c28e2eb",
 "target_type": "table",
 "triggers": []
}

out.lifecycle_id  # 'qlc_000191' — an attribute, not a key

This is a full replace, the same as the console's trigger editor: the list sent becomes the target's triggers, and every other property of the target is read back and written unchanged. A trigger object. name, goal and agentflow_id (24-character hex, from list-agents or get-process-flow; the part of a compound agent id before the dot is used) are required. Optional: start_from_agent_id (the agent inside the process flow to start from), trigger_id (or _id, to keep an existing trigger's id), search_filters (a list of {column, operator, value, type} like the filters on a schedule's table) and condition. A connector trigger also requires event, a named event on the connector (list them with connector-read on the connector's trigger actions). On a table or column target, condition is {condition_for, condition_query}: condition_for is insert (the default on a table), update or delete, and a column trigger must use update (it is the default there); an empty condition_query is built from search_filters. Any other condition_for is refused.

The trigger's internal kind is set from the target and is not a parameter.

A connector's triggers go through the connector's own update path, which re-registers the event subscription, so a trigger wired here is live. A table trigger fires on a row insert, update or delete, chosen with condition.condition_for and narrowed by search_filters. A column trigger is only evaluated when that column changes, so its condition_for is always update.

For what a trigger names and how a triggered run behaves, see list-triggers.

When the project's write gate is on, a call made with an API key or an SDK session waits for a person to approve it: the call returns 202 and an ApprovalRequired error carrying the approval id and a resume token, and the SDKs can wait for the decision and resume. The gate is off by default; a project admin can turn it on, or back off, in the project's settings, and it then holds admin API keys too. Actions taken by a person in the console are not held.

Marked consequential: it is audited in full, and a policy rule may hold it for a person to approve. See Policy and approvals.