The hard part is never the app on its own — it's the interface between the app and your n8n instance. This page takes on four tasks and shows both sides every time: what happens in n8n, and what happens in the app.
Two things are enough: the address of your n8n instance and an n8n API key. Both stay on the device — the key goes into the iOS keychain, not onto our servers.
https://my-instance.app.n8n.cloud — with no path after it.Then the Public API is not enabled on your instance. Some hosting plans and some self-hosting setups have it off by default. On self-hosted instances you can switch it on in the n8n settings or via environment variables; on a hosted plan, the tier decides.
Without the Public API no app can talk to your instance — ours included. That's not a WorkflowBuddy limitation, it's the interface itself.
Two common causes: the API key got truncated while copying, or the URL carries one path too many. Enter the plain base address — not the editor URL, and no /api/v1 at the end.
In your device's iOS keychain. If you want, Face ID or Touch ID guards access to the app and to revealing the key. We do not store your n8n API key.
You create a monitoring rule per workflow: what gets reported, how often it is checked, and when to stay quiet. The rest is handled by the monitoring on our server — even when the app is closed.
Nothing. And that's deliberate: WorkflowBuddy asks the n8n API about your workflows' executions. No error node is injected, no workflow is modified, nothing is installed in your instance.
Which also means: a workflow you create tomorrow can be monitored right away — no preparation needed.
Failure alerts for your most important workflow are the free entry point Free — one workflow, no time limit. Monitoring all workflows and the incident types canceled and stuck are Premium Premium, as are quiet hours and the finer check interval.
Work through three points in order: are notifications for WorkflowBuddy allowed in the iOS settings? Is there an active monitoring rule for exactly this workflow? And did it happen during your quiet hours?
If it stays quiet, send yourself a test notification from the rule. If that arrives, the delivery path is fine.
You choose between 5, 15, 30 and 60 minutes. The checking happens on our server, not on the phone — so the notification arrives even when the app is closed. The note "iOS minimum: 15 min" in the app only concerns refreshing the view in the background, not the alerts.
On the free tier, monitoring runs at the default of 15 minutes; choosing the interval is Premium. If you need it to the second, take the Push API: then the workflow reports the moment something happens.
One that started and is still running after a time span you set. Typically it is waiting for an external service that stopped answering. Open approvals explicitly don't count — those are allowed to wait.
For when your workflow knows best that there is something to say: one key from the app, one ordinary HTTP Request node in n8n — no code node, no signing.
wb_ and is then kept in this device's keychain.Add an HTTP Request node, method POST, and pass the key as a header. Plain JSON is enough as the body:
POST https://companion.amelus.de/api/notify
Authorization: Bearer wb_...
Content-Type: application/json
{
"title": "Invoice run failed",
"message": "Execution 4711 stopped at step 3",
"severity": "warning"
}severity is optional and accepts info, warning and critical; without it, info applies.
50 messages per day are free Free, Premium raises that to 500 per day Premium. Both are counted per device.
The key is unknown or was revoked. Rotating makes the old key invalid immediately — then the credential in n8n has to be replaced too. Also make sure the header really says Bearer in front of the key.
The daily or per-minute quota is exhausted. The response carries a Retry-After header telling you when it works again. A workflow in a loop is the usual cause.
Then our server accepted the message and passed it on, and iOS discarded it. Almost always, notifications for WorkflowBuddy are switched off. The app now tells you so on the Push API screen instead of reporting success and delivering nothing.
Yes, in as many as you like. Create it once in n8n as a Header Auth credential; then every workflow uses it and a key change is a one-place edit.
The workflow pauses and asks you; your answer continues it or stops it. In one sentence: a notification on your phone, one tap, and it moves on — without opening n8n.
Two standard nodes, no code.
https://companion.amelus.de/api/approval, header Authorization: Bearer wb_... (the same key as for the Push API). The body is set as an Expression:{{ JSON.stringify({
title: 'Invoice 4711',
message: 'Release payment of €2,400?',
resumeUrl: $execution.resumeUrl,
expiresAt: new Date(Date.now() + 60*60*1000).toISOString()
}) }}{{ $json.query.decision }}, telling the values approve and reject apart.expiresAt is set — the time remaining.There is no separate key to set up: approvals use the same Push API key, but have their own quota.
We walked into each of these ourselves; every one costs you half an evening:
$execution.resumeUrl through unchanged. Don't append anything, especially not ?decision=approve. Since n8n 2.33 the resume URL already carries a signature; a second ? destroys it, n8n answers 401, and nothing looks wrong in the instance log. The endpoint sets the decision parameter.
$execution.resumeUrl ends up in the request, and the approval has nowhere to go back to.
5 approvals per day are free Free — enough to try the whole thing on a real workflow — and Premium raises it to 200 per day Premium. This quota is separate from the one for ordinary messages: a chatty workflow can't eat your approvals.
Straight from the device to your own n8n instance. Our server passes the notification on and never stores the resume address. The app in turn only calls addresses whose host belongs to an instance you set up — a smuggled-in address leads nowhere.
No problem. The request is stored on delivery, not when you tap it. It sits as a card on the dashboard for as long as it is open.
The execution has been continued in the meantime, timed out, or was canceled. The most common cause while testing: the workflow was started again in the editor (see pitfall 3).
The app deliberately refuses every call to a foreign host. This happens when the workflow runs on an instance that is not (yet) set up in the app — or when that instance is stored there under a different address, e.g. internal rather than public.
Then the workflow didn't send an expiresAt. n8n does not communicate the Wait node's deadline by itself, so the workflow has to send it — without it the app would rather show the request with no countdown than invent a deadline.
Write to info@amelus.de or use the contact form. What's missing here usually belongs on this page — pointers are welcome.