Charge per call for your n8n workflows, see the margin on every run

Built with n8n
, , ,
1

Most of us build workflows that run quietly inside our own instance. But if a
workflow starts with a Webhook node and ends with a clean Respond to Webhook JSON
object, it is already an API. The only missing piece is a way for someone outside
your instance to pay to call it, and a way to see what each run actually costs you.

I have been building n8n integrations for Alephant to close that gap, and the
verified nodes plus a full x402 walkthrough are now live.

What Alephant is, briefly

Alephant is an open-source, Rust-built, OpenAI-compatible gateway that sits
between your workflows and 50+ model providers. It does three things: it routes
model calls and traces every agent run, it enforces budgets and policy before a
call executes, and it lets you publish a workflow as a per-call paid endpoint. It
sits above x402 as the governance and accounting layer, it is not a payment rail
itself, and it never takes custody of your provider keys. It is GPL v3 and free to
test with no credit card.

The three verified n8n nodes

All three are verified on n8n. Open the node picker in any workflow, search
alephant, and they appear together. No package name needed.

  • Alephant Cost Control (@alephantai/n8n-nodes-alephant-ai) sends OpenAI-compatible chat completion requests through the gateway, so every model call from your
    workflow gets full cost attribution and usage tracking under one virtual key.
  • Alephant AI Analytics (@alephantai/n8n-nodes-alephant-analytics) is read-only.
    It pulls usage summaries, cost by model, daily costs, budget status, and request
    logs back into a workflow, so you can build spend monitoring and alerting on top
    of your own automations.
  • Alephant AI Analytics Tool is the agent-tool version of the analytics node,
    auto-dropped into AI agent steps so an agent can query its own spend and budget
    mid-run.

Use case 1: a workflow that pays for itself

This is the one I wrote the full guide for. An existing workflow (the example is a
SERP ranking analysis) becomes an endpoint that another developer or agent pays a
few cents to call. The workflow logic does not change. Webhook in, Respond to
Webhook out. You point Alephant at the production Webhook URL, set a price per
call, and it handles the x402 payment challenge before the workflow runs.

The path:

Buyer or agent
→ x402 paid endpoint
→ Workflow Agent
→ n8n production Webhook URL
→ your normal workflow runs
→ Respond to Webhook JSON
→ trace, cost, revenue, and margin record

Because payment is verified first, unpaid calls return a 402 and never trigger the
workflow, so they cannot burn your model or API budget. Every paid call logs
revenue minus model cost minus tool cost, so you can finally answer whether a given
endpoint actually earns.

Full walkthrough: n8n Workflow x402 Endpoint | Alephant Documentation

Use case 2: cost visibility inside your existing workflows

You do not have to monetize anything to get value here. Route your AI steps through
the Cost Control node and every call is attributed under a virtual key. Then run a
scheduled workflow with the Analytics node that pulls daily cost and budget status,
and have it post to Slack or email when spend crosses a threshold. That gives you a
FinOps supervisor built entirely in n8n.

Links

Happy to answer Webhook-contract or node-setup questions in the thread.

4

The per-call margin visibility angle is exactly what’s missing when you’re building SaaS on top of n8n - most people only discover the cost problem after they’ve already shipped. The workflow-as-API pattern you described (Webhook in, Respond to Webhook out) maps well to a metered billing model. One thing that becomes important at scale: if a single workflow call triggers multiple sub-workflows, you’ll want Alephant to trace cost at the root call level, not just per LLM call, so the margin stays accurate even for deeply nested executions.

1 Like