Use Cases

Sintax is general-purpose, but it was designed around a specific kind of problem: systems where data flows through multiple steps, each step producing values the next step depends on.

Workflow engines

Workflow definitions often look like a map of named values where later steps reference earlier ones:

steps:
  fetch_url:   "https://api.example.com/{{ env }}/items"
  response:    "{{ fetch_url }}"            # resolved after fetch_url
  items:       "{{ response | from:'json' | key:'data.items' | default:[] }}"
  count:       "{{ items | length }}"
  summary:     "Found {{ count }} items in {{ env }}"

Sintax resolves the dependency graph automatically, so you don't have to manually order steps or track which variables each step needs. The engine also tells you the resolved order - useful when your workflow executor needs to schedule steps.

deps, _ := s.ExtractDependencies(vars)
// ["fetch_url", "response", "items", "count", "summary"]

// Evaluate a branch condition
proceed, _ := s.ResolveCondition("{{ count | gt:0 }}", vars)

API response transformation

Transform raw API responses into exactly the shape your application needs - no intermediate structs required:

{{ response | from:'json' | key:'data.users' | filter:'active',true | sort:'name' | json:'pretty' }}

Or extract a single field from a deeply nested response:

{{ payload | from:'json' | key:'result.metadata.created_at' | format:'YYYY-MM-DD' }}

Configuration generation

Build environment-specific configuration from a shared base:

base_url:    "https://{{ subdomain }}.example.com"
api_url:     "{{ base_url }}/api/v{{ api_version }}"
cdn_url:     "{{ base_url | replace:'https','https://cdn' }}"
db_name:     "{{ app_name | slug }}_{{ env }}"

Sintax resolves these in dependency order, so api_url is always resolved after base_url, regardless of declaration order.

Dynamic output formatting

Format values for display without changing your data model:

# File paths
{{ file_path | dirname }}           → /usr/local/share
{{ file_path | filename }}          → config.json
{{ file_path | ext }}               → json
{{ file_path | ext-prepend:'min' }} → config.min.json

# Text formatting
{{ post_slug | title }}             → My Post Title
{{ title | slug }}                  → my-post-title
{{ body | shorten:160 }}            → First 160 characters...

# Dates
{{ created_at | format:'YYYY-MM-DD' }}  → 2026-04-16
{{ now | format:'D, d M Y' }}           → Thursday, 16 Apr 2026

Conditional content

Render different output based on resolved values:

{{ if user_role | eq:'admin' }}
Full access granted.
{{ else }}
Limited access. Contact your administrator.
{{ /if }}

Or inline with ternary:

Status: {{ is_active ? 'Active' : 'Inactive' }}
Items: {{ count | gt:0 ? count : 'none' }}

Collection reshaping

Transform lists into exactly the structure downstream consumers expect:

# Filter and reshape
{{ users | filter:'verified',true | sort:'name' }}

# Find a specific record
{{ orders | find:'id',order_id | key:'total' | default:0 }}

# Convert list to lookup map
{{ products | map:'sku' }}   → { "SKU-001": {...}, "SKU-002": {...} }

# Wrap a value in a named container
{{ user_id | wrap:'user' }}  → { "user": 42 }

Graceful fallbacks

Use default to avoid hard failures when data is missing or optional:

{{ config | from:'json' | key:'timeout' | default:30 }}
{{ user | key:'profile.avatar' | default:'https://example.com/default.png' }}
{{ tags | filter:'featured' | first | default:'general' }}

The default modifier catches missing-variable errors as well as modifier failures, so you can build resilient pipelines that degrade gracefully.

How is this guide?