---
title: "Retrieve Workflow Templates"
method: GET
path: "/v1/workflows/templates"
tags: ["Workflows", "Reference Data", "v1"]
---

# Retrieve Workflow Templates

`GET /v1/workflows/templates`

Retrieve the pre-built workflows you can start from, each a ready-made definition with the values that depend on your account left out.

A template is the quickest route to a working workflow: instead of wiring triggers and steps yourself, take a template's `definition`, fill in its `variables`, and post the result to **Create Workflow**.

Wherever a value has to be supplied, the `definition` carries a `{{variables.<name>}}` placeholder, and the matching entry under `variables` says what that value is for and what it accepts — its `entity_type`, whether it takes a list (`array`), and the values it is restricted to (`available_options`), if any.

A placeholder always takes up the whole value it stands in for and is never part of a longer string, so filling one in means replacing the whole string. That is also what lets a variable hold an array or a number rather than only text. One variable may appear in more than one place — a CRM connection used by two export steps is one variable — and the value you supply goes into every placeholder that names it.

A definition still holding a placeholder is **not** a valid definition. It is accepted by **Create Workflow**, which stores a definition without validating it, but the workflow cannot be enabled until every placeholder is replaced.

The list is the same for every account — it describes what the platform ships, not what the account has set up. Templates are added and revised over time, so treat the list as open-ended; a template's `id` is stable and can be stored.

Credit Note: Retrieving templates does not consume credits.

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

## Query parameters

- `account_id` string, required

## Response `200`

Success

- object
  - `data` WorkflowTemplateV1[], required
    - `type` 'workflow_template', required — The type of the object.
    - `id` string, required — The template's unique identifier. Stable across releases, so it can be stored.
    - `attributes` object, required
      - `name` string, required — What the template does, in a few words.
      - `description` string, required — What the template is for, in a sentence.
      - `categories` string[], required — What the template is for, as the categories our app groups templates under. Templates may belong to more than one.
      - `workflow_type` string, required — The `workflow_type` the workflow will have once created — what the template's trigger hands over. A template started by the clock rather than by a company reports `time`.
      - `definition_version` 'V1', required — The version the template's `definition` is written in.
      - `definition` object, required — The template's definition, with a `{{variables.<name>}}` placeholder wherever a value has to be supplied. **Not** accepted as sent: every placeholder has to be replaced before the definition can be posted to **Create Workflow**.
        - `triggers` object[], required — The events that start the workflow. The workflow runs when any one of them fires. All triggers of a workflow must produce the same `entity_type`. An empty array is accepted on a workflow that is still being put together, but a workflow cannot be enabled without at least one trigger.
          - `name` string, required — The name of the trigger definition this entry configures, as returned by **Retrieve Workflow Trigger Definitions**.
          - `filters` object[], required — Narrows down which occurrences of the event start the workflow. A workflow starts when **any** of its filters matches, so listing the same attribute twice widens the trigger rather than narrowing it.
            - `attribute` string, required — The filter to apply, taken from the trigger definition's `filters`.
            - `op` 'eq' — How `value` is compared against the event.
            - `value` union, required — The value to compare against. Its type follows the `entity_type` of the matching filter on the trigger definition.
              - …
          - `options` object — Values for the trigger definition's `options`, keyed by option name. Each value follows the `entity_type` declared for that option.
        - `steps` object, required — The workflow's steps, keyed by step id. Step ids are chosen by the caller, are unique within the workflow, and are what `order` refers to. The id `trigger` is reserved.
        - `order` object, required — How the steps are wired together, keyed by step id. The value is the list of steps that run after that step — several entries mean the workflow branches and each branch runs. The special key `trigger` holds the steps that run first, right after the workflow starts. An entry is either a step id, or a condition object that picks the next step based on the resource flowing through the workflow. A step id that is not defined in `steps`, or a cycle, is rejected when the workflow is enabled.
      - `variables` object, required — The values to supply, keyed by the name used in the `{{variables.<name>}}` placeholders in `definition`. A placeholder always takes up the whole value it stands in for and never part of a longer string, so filling one in means replacing the whole string — which is what lets a variable hold an array or a number rather than only text. One variable may appear in more than one place: a CRM connection used by two export steps is one variable, and the value you supply for it goes into every placeholder that names it.
  - `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

## Changes

> 15 revisions in range; 1 not diffed, 2 could not be searched.

- **2026-08-24** `a12941d83e55` — 1 info
  - endpoint added

[Change history](https://skmtc.dev/leadfeeder/apis/leadfeeder-public-api/changes/v1/workflows/templates/get.md)

---

[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)