Skip to main content
Templates are pre-built flow blueprints. They have the same shape as a flow definition — inputs, variables, steps, webhooks — plus a category and tags for browsing. The template endpoints are public: no authentication required.

​
Browse templates

curl "$BASE_URL/templates"
Filter by status or category: 
curl "$BASE_URL/templates?status=active&category=contact-center"
Query parameterDescription
statusactive, draft, or archived
categoryCategory label, e.g. contact-center, utils
limit / skipPagination (default 50 / 0)
Fetch one template in full: 
curl "$BASE_URL/templates/tmpl_echo_demo"
The response carries everything a definition needs: name, description, category, tags, version, status, inputs, variables, steps, and webhooks.

​
Instantiate a definition from a template

Templates are read-only — to use one, copy its shape into a new definition of your own via POST /definitions. Take the template’s inputs, variables, steps, and webhooks, then supply your own name and status: 
TEMPLATE=$(curl -s "$BASE_URL/templates/tmpl_echo_demo")

echo "$TEMPLATE" | jq '{
    name: "My flow from template",
    status: "active",
    inputs: .inputs,
    variables: .variables,
    steps: .steps,
    webhooks: .webhooks
  }' | curl -X POST "$BASE_URL/definitions" \
    -H "X-API-Key: $GETDIALED_API_KEY" \
    -H "Content-Type: application/json" \
    -d @-
The new definition is yours to edit freely — swap in your own connection_id on each task, adjust parameters, and re-PUT as needed. Changes to the definition never affect the template.
Most templates that call external platforms leave connection_id unset on their tasks. Create a connection first and set it on each task before activating.
Set "status": "draft" (or omit status) if you want to review and edit before the flow becomes triggerable — only active definitions can be triggered.

​
Next steps

Build your first flow

Author a definition from scratch instead.

Flow definitions

Every field of the definition shape, explained.