Automation

A workflow engine built for commerce. An event comes in — an order is paid, a payment fails, a customer signs up — and Lunixi runs the workflow you designed: branch on conditions, look up the payment or customer, render a template, and send an email or SMS through your own provider.

It is n8n-grade, but payment- and commerce-native: triggers map to canonical commerce.* events, lookups read directly from your payments and subscriptions, and every run is idempotent, tenant-isolated and fully observable.

How a workflow runs

1. Trigger — a platform event, a signed inbound webhook, a cron schedule, or a manual run starts the flow.
2. Resolve — the engine loads the published version of the flow (drafts never fire side effects).
3. Execute — it walks the graph node-by-node: conditions branch, lookups enrich, templates render, actions send.
4. Persist — every run, every node attempt, and every outbound delivery is recorded as a redacted, queryable event.

Triggers

A workflow starts from one of four sources.

Canonical commerce events

Inbound storefront events are normalised to a canonical taxonomy, so a flow written once works regardless of the source platform:

Node catalog

A flow is a graph of typed nodes. Every node reads its inputs from upstream output using {{ }} expressions and writes its result to a saveAs variable that later nodes can reference.

Logic & control

Data

Actions (side-effecting)

Referencing data between nodes

Any node config field can interpolate values resolved at runtime:

{{ input.payload.order.total }}        // the triggering event
{{ vars.customer.email }}              // output a prior node saved
{{ nodes.lookup_pay.output.status }}   // a specific node's result

A bare {{ vars.customer }} returns the raw object; embedded {{ }} inside a string interpolates.

Bring your own providers

send_email, send_sms and send_invoice deliver through your provider account with your API key — Lunixi never sits in the middle as a sending service. You connect a provider once, store the credential in the vault, and reference it from any node.

The generic HTTP provider is an escape hatch: define the full request (URL, method, headers, body) for any provider not in the list.

{
  "type": "send_email",
  "config": {
    "provider": "sendgrid",
    "apiKeySecretRef": "vault:sg_prod",
    "to": "{{ vars.customer.email }}",
    "templateId": "welcome_v2",
    "variables": { "name": "{{ vars.customer.firstName }}" },
    "saveAs": "emailResult"
  }
}

Flow engine

Quickstart

Build, simulate and publish a flow with the management API. All management calls use a bearer token (at_live_…); merchantId is resolved from the key, never sent in the body.

# 1. Create a draft
curl https://api-gateway.lunixi.com/api/v1/automation/flows/draft \
  -H "Authorization: Bearer at_live_5f3e2b1a..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Welcome email on signup",
    "nodes": [ /* start → lookup_customer → send_email → stop */ ]
  }'
 
# 2. Validate, then dry-run simulate (no side effects)
curl https://api-gateway.lunixi.com/api/v1/automation/flows/{id}/simulate \
  -H "Authorization: Bearer at_live_5f3e2b1a..." \
  -d '{ "input": { "payload": { "customerId": "cus_123" } } }'
 
# 3. Publish (immutable version)
curl https://api-gateway.lunixi.com/api/v1/automation/flows/{id}/publish \
  -H "Authorization: Bearer at_live_5f3e2b1a..." -d '{}'
 
# 4. Manual run
curl https://api-gateway.lunixi.com/api/v1/automation/flows/{id}/run \
  -H "Authorization: Bearer at_live_5f3e2b1a..." \
  -d '{ "input": { "payload": { "customerId": "cus_123" } } }'

Inbound webhooks

To drive flows from your storefront, register an integration to get a signed ingress URL and an HMAC secret (shown once). Events are posted to:

POST https://api-gateway.lunixi.com/api/v1/automation/integrations/{provider}/{integrationId}/events

Each request is authenticated by signature — no bearer token:

SIG=$(printf '%s.%s' "$TS" "$BODY" \
  | openssl dgst -sha256 -hmac "$SIGNING_SECRET" -hex | sed 's/^.* //')
 
curl https://api-gateway.lunixi.com/api/v1/automation/integrations/wordpress/intg_123/events \
  -H "X-Automation-Signature: sha256=$SIG" \
  -H "X-Automation-Timestamp: $TS" \
  -d "$BODY"

The response status reflects the outcome so your producer can retry correctly: 202 accepted, 200 duplicate, 401 bad signature, 404 no matching flow, 409 replayed nonce, 413 body too large, 429 rate-limited.

Security & multi-tenancy

Observability

Every surface is queryable, redacted and merchant-scoped:

• Overview — run volume, success rate, latency and recent failures over a rolling window.
• Run history — per-flow runs, drillable to a node-by-node trace.
• Trigger events — the inbound ingest log.
• Connector deliveries — the outbound HTTP egress log.
• Audit events — an append-only trail of flow changes.

{
  "runId": "run_01HV3K9X...",
  "flowId": "flow_8f2a9c",
  "status": "success",
  "latencyMs": 412,
  "path": ["start", "if", "lookup_customer", "send_email", "stop"],
  "nodes": [
    { "id": "lookup_customer", "status": "success" },
    { "id": "send_email", "status": "success", "output": { "delivered": true } }
  ]
}

Related

• Automation Workflows — worked, end-to-end flow examples
• Payment Gateway — the payment events that trigger flows
• Fraud Detection — gate sends and actions on risk signals