---
title: "Retrieve Workflow Trigger Definitions"
method: GET
path: "/v1/workflows/trigger-definitions"
tags: ["Workflows", "Reference Data", "v1"]
---

# Retrieve Workflow Trigger Definitions

`GET /v1/workflows/trigger-definitions`

Retrieve every event a workflow can be started by, each with the filters that narrow it down and the options it can be configured with.

Use this before creating or updating a workflow: a trigger's `name` is what goes into a trigger's `name`, and the keys of its `filters` are the `attribute` values its filters can use.

A trigger's `output` decides what the workflow's first steps are handed, and therefore the workflow's `workflow_type`. All triggers on one workflow must produce the same `entity_type`.

The list is the same for every account — it describes what the platform supports, not what the account has set up. Triggers are added over time, so treat the list as open-ended and ignore any trigger you do not recognise.

Credit Note: Retrieving trigger definitions does not consume credits.

:::info
Requires the `workflows:read` OAuth2 scope.
:::

## Query parameters

- `account_id` string, required

## Response `200`

Success

- object
  - `data` WorkflowTriggerDefinitionV1[], required
    - `type` 'workflow_trigger_definition', required — The type of the object.
    - `id` string, required — The trigger's name — the value to put in a trigger's `name`. Also its unique identifier.
    - `attributes` object, required
      - `name` string, required — The trigger's name. Identical to `id`.
      - `output` object, required — What the trigger hands over to the workflow's first steps, and what therefore sets the workflow's `workflow_type`. All triggers on one workflow must agree on this.
        - `entity_type` string, required — The kind of value a workflow input, option, filter or output carries. **Resource types** refer to Leadfeeder entities. Their value is the entity's id, as a string: `company`, `company_list`, `contact`, `contact_list`, `tag`, `custom_feed`, `custom_field`, `list_view`, `saved_search`, `crm_company`, `crm_contact`, `crm_lead`, `crm_opportunity`, `crm_task`, `hmac_secret`. **Primitive types** carry a literal value: `string`, `integer`, `boolean`, `time`, `object`, `http_response`. `any` means the step accepts (or produces) whatever the preceding step passed along, whatever its type. New entity types are introduced as new actions and triggers ship. Treat this as an open set rather than a fixed list, and ignore values you do not recognise.
      - `filters` object, required — How occurrences of the event can be narrowed down, keyed by filter name. A filter marked `required` must be set before the workflow can be enabled — without it the trigger would fire on every occurrence of the event in the account.
      - `options` object, required — How the trigger can be configured, keyed by option name. Unlike `filters`, options do not decide whether the trigger fires.
  - `meta` object, required
    - `num_results` integer, required — The total number of results returned.
    - `request_id` string, required — A unique identifier assigned to each API request for end-to-end traceability.

## Other responses

- `400` — Bad Request
- `401` — Unauthorized. The request was rejected because the credentials are missing, invalid, expired, or have been revoked. The client must re-authenticate before retrying. Clients can differentiate via the `code` value of the first item in `errors`.
- `403` — Forbidden. The credentials are valid but the caller is not authorized to perform the request — typically because the user lacks the required permission, the OAuth scope is insufficient, the subscription plan does not include the required entitlement, the `account_id` does not belong to the authenticated user, or the target list is read-only and its members cannot be modified. Clients can differentiate via the `code` value of the first item in `errors`.
- `429` — Too many requests. Either the per-second rate limit or the monthly quota configured for the API key / OAuth application has been exceeded. Clients can differentiate via the `code` value of the first item in `errors`.
- `500` — Internal server error
- `504` — Server timeout

---

[API](https://skmtc.dev/leadfeeder/apis/leadfeeder-public-api.md) · [All operations](https://skmtc.dev/leadfeeder/apis/leadfeeder-public-api/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/leadfeeder/leadfeeder-public-api/revisions/3b95d5a53148/schema)