Automations

An automation is a rule stored on your panel: when an event of a given type arrives and every condition matches, run an action. No infrastructure needed on your side.

curl -X POST "$BASE/api/crm/$CRM/automations" \
  -H "X-API-Key: $KEY" \
  -H "Content-Type: application/json" \
  -d '{
        "name": "Thank big tippers on Discord",
        "trigger_event": "new_tip",
        "conditions": [
          { "field": "payload.amount", "op": "gt", "value": 20 }
        ],
        "action_type": "discord",
        "action_params": {
          "url": "https://discord.com/api/webhooks/…",
          "message": "💸 {payload.fan.username} tipped ${payload.amount}"
        },
        "is_active": true
      }'

Conditions

A list, joined with AND. Every condition must match for the action to run. An empty list matches every event of that type.

{
  "conditions": [
    { "field": "payload.amount", "op": "gt", "value": 5 },
    { "field": "payload.fan.username", "op": "neq", "value": "banned_user" }
  ]
}

field is a dotted path into the event envelope, so event_type, of_user_id, occurred_at and anything under payload. are all addressable.

Operators

Actions

Templating

Any message supports {dotted.path} interpolation against the event, resolved at dispatch:

"💸 {payload.fan.username} tipped ${payload.amount} on {occurred_at}"

Templating applies to every string in action_params — url, tag, to_fan_id, nested objects and arrays — not just message. Credential keys (bot_token, secret, token, api_key, password) are deliberately excluded and passed through byte-for-byte.

An unresolvable path renders as an empty string, not as literal {…}. A typo silently leaves a hole in the message ("💸 tipped $") rather than announcing itself — check the first delivery.

Managing automations

GET    /automations                    # list
POST   /automations                    # create
GET    /automations/{id}               # read one
PATCH  /automations/{id}               # update (send {"is_active": false} to pause)
DELETE /automations/{id}
POST   /automations/{id}/run-now       # fire the action immediately, for testing
GET    /automations/{id}/runs          # run history

run-now validates an action without waiting for a real event — but it builds a synthetic event from the sample_payload you supply, so send one. Without it the payload is empty, every payload.* condition fails, and the run is recorded as skipped.

curl -X POST "$BASE/api/crm/$CRM/automations/$ID/run-now" \
  -H "X-API-Key: $KEY" -H "Content-Type: application/json" \
  -d '{"sample_payload": {"amount": 25, "fan": {"id": "987", "username": "somefan"}}}'

The response is {"status": "success" | "skipped" | "failed"}. GET /runs (default 50, max 200) has the history.

POST /automations also accepts of_user_id to scope a rule to one connected account — the per-account routing that webhooks cannot do.

Worked examples

{
  "name": "VIP tagging",
  "trigger_event": "new_purchase",
  "conditions": [{ "field": "payload.amount", "op": "gte", "value": 100 }],
  "action_type": "tag_fan",
  "action_params": { "tag": "vip" }
}

{
  "name": "Account needs reconnecting",
  "trigger_event": "polling_paused",
  "conditions": [],
  "action_type": "telegram",
  "action_params": {
    "bot_token": "123456:ABC…",
    "chat_id": "-1001234567890",
    "message": "⚠️ Polling paused for {of_user_id} — {payload.reason} ({payload.failures} failures)"
  }
}

{
  "name": "Welcome DM",
  "trigger_event": "new_subscriber",
  "conditions": [],
  "action_type": "send_dm",
  "action_params": {
    "message": "Hey {payload.fan.display_name}, thanks for subscribing 💕",
    "to_fan_id": "{payload.fan.id}"
  }
}

Automations, webhooks, or your own code?

Automations are the right tool when the reaction is a notification or a simple one-step side effect. Once you need branching logic, external data, or state, use a webhook and do the work in your own service.

Both run from the same event emission, so you can use them together — an automation for the Discord ping, a webhook for your database.