my-workflow-api

name	my-workflow-api
version	1.0.0
description	Run actions when a webhook fires. Trigger emails, Slack notifications, or HTTP calls in response to inbound webhook deliveries — without writing a backend.
triggers	["workflow","automation","on webhook","send email on","slack notification","payload templating","drip","trigger","run"]
checksum	sha256-pending

MyWorkflowAPI

Workflows bind a list of steps to a webhook endpoint. Every time the webhook receives a POST, the workflow runs its steps in order. Each run is recorded with status, attempt count, and any error.

Capabilities

A workflow is the "do something when X happens" layer. The trigger is always a mywebhookapi endpoint. Steps run sequentially per inbound delivery; failed runs don't block subsequent runs and don't affect the stored webhook delivery.

Step types today:

Type	Aliases	Required fields
send_email	email	from, to, subject, plus one of body / html / template_id
slack_message	slack	webhook_url, text
http_request	http	url (optional: method, body, headers)
enqueue_job	enqueue	queue (optional: payload, dedup_key, delay_seconds) — hands durable work to my-queue-api

All step types support payload templating with {{ payload.fieldname }}. The webhook payload is the entire POST body; named fields are accessed dotted. Whitespace inside braces is fine — both {{ payload.email }} and {{payload.email}} work.

Unknown step types are rejected at create time, so typos surface immediately rather than after 3 failed retries during execution.

Workflows can be created --no-enable so you can test the flow before going live.

Commands

Command	What it does
myapi workflow create "<name>" --endpoint-id <id> --steps '<json>' [--no-enable]	Create a workflow
myapi workflow list	List workflows in your org
myapi workflow get <id>	Inspect steps + trigger config
myapi workflow update <id>	Change name, endpoint, or steps
myapi workflow enable <id>	Enable firing
myapi workflow disable <id>	Stop firing without deleting
myapi workflow delete <id>	Permanently remove workflow + run history
myapi workflow runs <id>	List recent runs (status, attempt, errors)
myapi workflow get-run <run_id>	Get full run details + step output

Examples

# 1. Webhook to act on
WID=$(myapi webhook create "leads" --json | jq -r .id)

# 2. Workflow that pings Slack on every inbound POST
myapi workflow create "Slack on new lead" \
  --endpoint-id $WID \
  --steps '[{"type":"slack","webhook_url":"https://hooks.slack.com/...","text":"new lead!"}]'

# 3. Trigger it
curl -X POST <webhook-inbound-url> -d '{"name":"Alice"}'

# 4. Inspect runs
myapi workflow runs <workflow_id>
myapi workflow get-run <run_id>

# Test before going live
myapi workflow create "X" --endpoint-id $WID --steps '...' --no-enable
# ... iterate ...
myapi workflow enable <id>

Multi-step example with payload templating

[
  {
    "type": "send_email",
    "from": "[e-mail]",
    "to": "{{ payload.email }}",
    "subject": "Thanks, {{ payload.name }}",
    "template_id": "<template_id>"
  },
  {
    "type": "slack",
    "webhook_url": "https://hooks.slack.com/services/T.../B.../xxx",
    "text": "New submission from {{ payload.name }} ({{ payload.email }}): {{ payload.message }}"
  }
]

Notes

• Workflows fire on every webhook delivery. Failed runs don't block subsequent runs.
• Each run records attempt number, started_at/finished_at, and any error.
• Disable to stop firing without losing the configuration.
• Deleting a workflow purges its run history; the webhook endpoint remains. Look before you delete: myapi workflow list first, pass --org explicitly; delete asks for confirmation — --yes required in non-interactive runs.

See also

workflow is one of three orchestration slots. Use workflow to react to inbound webhooks; use my-queue-api for durable retried machine work; use my-task-api for work that needs an agent/human decision. Full comparison: docs/orchestration-decision-guide.md.

Run myapi workflow --help for full flag reference.