> Source: https://wexa.ai/docs/automation/list-triggers

# list-triggers

List the triggers attached to one target, or to every target of one kind in this project. Needs the `fabric:orchestrate.read` grant.

**List triggers**

**Wexa MCP server**

```bash
curl -sS -X POST https://fabric.wexa.ai/mcp/$FABRIC_PROJECT_ID \
  -H "authorization: Bearer $FABRIC_API_KEY" \
  -H "Mcp-Session-Id: $MCP_SESSION_ID" \
  -H "content-type: application/json" -H "accept: application/json" \
  -d '{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"list-triggers","arguments":{"target_type":"agent"}}}'
```

```json
{
  "content": [
    {
      "type": "text",
      "text": "{\"lifecycle_id\":\"qlc_000190\",\"result\":{\"triggers\":[]}}"
    }
  ],
  "isError": false
}
```

**REST API**

```bash
curl -sS https://fabric.wexa.ai/v1/list-triggers \
  -H "authorization: Bearer $FABRIC_API_KEY" \
  -H "content-type: application/json" \
  -d '{"target_type":"agent"}'
```

```json
{
  "lifecycle_id": "qlc_000190",
  "result": {
    "triggers": []
  }
}
```

**TypeScript SDK**

```ts
import { Fabric } from '@wexa-fabric/sdk'

const fabric = new Fabric()
const result = await fabric.listTriggers({
  target_type: 'agent'
})
```

```ts
// result is the payload itself, with no `.result` to read
{
  triggers: []
}
```

**Python SDK**

```python
from wexa import Fabric

fabric = Fabric()
out = fabric.list_triggers(
    target_type="agent",
)
```

```python
# out is the result, already unwrapped
{
    "triggers": []
}
```

## Parameters

| Parameter | Type | Required | Notes |
| --- | --- | --- | --- |
| `target_type` | string | Required | One of: `agent`, `connector`, `table`, `column`. Required because a scan across all four would not finish inside the SDK's call timeout on a large project. |
| `target_id` | string | Optional | agent: `<container>.<agent>` from `list-agents`. connector: the connector id. table: the table id from `list-tables`. column: `<table_id>.<column_id>`. Omit it to list every target of this kind. A target of that kind in this project; a connector that is not found is reported as 502. A column id not in `<table_id>.<column_id>` form is refused. |

**Show full response**

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

**Result of list-triggers**

**REST API**

```json
{
  "lifecycle_id": "qlc_000190",
  "result": {
    "triggers": []
  }
}
```

**TypeScript SDK**

```ts
// the object you get back IS the result — there is no `.result` to read
{
  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_000190'
```

**Python SDK**

```python
# a dict subclass; `result` is already unwrapped
{
 "triggers": []
}

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

**More details**

A trigger starts an agent or a process flow without a person asking. It is configured as part of a target's definition, as a list of triggers, not as a separate object you run. Each one names what to start (the process flow to run, and optionally the agent inside it to start from), what to ask for (a `goal` in natural language, as a person starting the run by hand would supply) and when to fire (a scheduled time, or a condition and filters describing the event that should set it off).

In the console, open the agent, then **Triggers**, and choose **Add**. Give the trigger a name, select a process flow, optionally select the agent to start from, and write the goal. Connector triggers are edited under **Connectors**: the agent's Triggers panel lists the connector triggers that also start it, and shows one as paused when it is.

A triggered run is not a special kind of run. It produces an [execution](/docs/agents/agent-versions) like any other, records the same inputs and outputs and is governed by the same [policy decisions](/docs/governance/policy-and-approvals). Nothing is exempt from a rule because a trigger started it. Starting a run (a person calling `run-agent`, or a trigger) is a separate decision from granting skills.

An agent can have skills and no trigger, a trigger and no skills, or both: a trigger is about when it runs, skills are about what it can do. Each trigger carries the shape described under [`set-triggers`](/docs/automation/set-triggers).

Change them with [`set-triggers`](/docs/automation/set-triggers). To run an agent or process flow on a repeating or one-off time without defining a trigger, use a [schedule](/docs/automation/create-schedule).

Not marked consequential: it is audited lightly and the project's write gate never holds it.

Every tool call works the same way: [How every tool call works](/docs/sdks-and-apis/how-every-tool-call-works).