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
<!-- llm:start -->
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.
<!-- llm:end -->

## Commands
<!-- generated:start -->
| 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 |
<!-- generated:end -->

## Examples
<!-- llm:start -->
```bash
# 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

```json
[
  {
    "type": "send_email",
    "from": "[email protected]",
    "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 }}"
  }
]
```
<!-- llm:end -->

## 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.