For those running n8n workflows for multiple clients. One OpenAI/Anthropic account, several clients’ workflows on it. How do you actually know who used what when the bill comes?
I’ve seen people use the “log costs to Google Sheets” template workflows, some just estimate on the invoice, some make each client bring their own API key. Curious what actually holds up at 5+ clients, especially when re-billing with a markup.
Also, has anyone had a workflow loop and quietly burn through credits before you noticed? How did you catch it?
1 „Gefällt mir“
are they bringing their own key or is it all on your account? that fork changes every answer downstream.
the sheets-logging templates hold up fine until you add a sub-workflow call or a parallel branch, then attribution quietly goes sideways. execute-workflow nodes don’t carry the parent’s client tag unless you pass it through explicitly, so the sub-workflow’s tokens land in whatever bucket it defaults to. at 5+ clients that’s where the markup math starts lying to you.
the loop thing is real. had a webhook retry chain go infinite because my error handler was hitting the same endpoint, ate about $40 in tokens before i noticed. what actually saved me was a hard monthly cap at the provider, not anything inside n8n, since a runaway workflow won’t stop itself but the api will. then a cheap alert on any workflow firing more than X times an hour.
are you marking up raw cost or flat fee on top? changes whether you need per-call precision or just a decent estimate.
The attribution problem across sub-workflows is the real issue - the Google Sheets logging template breaks the moment you call Execute Workflow.
What holds up at 5+ clients: tag every workflow name with a client prefix in n8n itself (e.g., [ClientA] Lead Scorer), then after each OpenAI/Anthropic call, log $workflow.name, $execution.id, and usage.total_tokens from the API response to a Postgres or Airtable table. The workflow name carries through sub-workflow executions and gives you a reliable attribution trail even when calls are nested.
For the runaway loop issue - hard monthly caps at the API provider level plus a rate check in workflow static data (if runs-per-hour exceeds X, stop and alert) is the only reliable defense. The Sheets log catches it after the fact; the static data counter catches it before the damage compounds.
mostly on my account, which is why the fork hurts. Client-owned keys kill the markup option and cost-plus markup, so per-call precision matters, can’t invoice off estimates. your provider-cap point is the one that stuck: enforcement has to live at the api boundary, nothing inside n8n can stop a loop n8n is running. that’s basically what I ended up building. Per-client caps enforced at the boundary + a usage statement per client. launching this week, free credits if you want to break it