---
title: "List the automated actions a flow may perform"
method: GET
path: "/api/v1/rest/workflow/actions"
tags: ["Workflows"]
---

# List the automated actions a flow may perform

`GET /api/v1/rest/workflow/actions`

## Request

- Base URL: `https://api.custodo.ai`
- URL: `https://api.custodo.ai/api/v1/rest/workflow/actions`
- Auth: HTTP bearer

The catalogue an admin picks a flow’s automated step from — every other module’s own write tool, filtered to what THIS tenant may actually run (the owning module enabled, its tier held, workflow.automation bought). An entry not listed here would save into a flow and then fail on its first run. Same gate as authoring a flow (workflow:flows:manage) — a builder tool, not something workflow_start needs.

**Examples**

- What can an approval flow do automatically?
  `GET /api/v1/rest/workflow/actions`

## Headers

- `X-Tenant-Id` string, uuid

## Response `200`

Done. `data` is the tool’s own answer.

- RestResult
  - `ok` true, required
  - `data` unknown, required

## Other responses

- `400`: The arguments did not validate: `error.message` names the field, what it expects and what arrived.
- `401`: No API key, or one that is malformed, unknown, revoked or expired.
- `403`: The call never ran: the module is off for this organisation, the credential lacks the permission or the module, the tier does not cover it, or the tool is destructive and the key was not minted for that.
- `422`: The tool ran and refused, in a sentence of its own (`TOOL_REFUSED`): the message says what to change. Retrying the same call will not help.
- `429`: The API key has spent its minute, or its day. Every request a key makes counts. See `Retry-After`.

---

[API](https://skmtc.dev/custodo/apis/custodo-integrazioni.md) · [All operations](https://skmtc.dev/custodo/apis/custodo-integrazioni/llms.txt) · [OpenAPI document](https://skmtc.dev/custodo/apis/custodo-integrazioni/revisions/16d336d3ec2a?raw)