How are people connecting Paperclip with n8n?
Sri Krishna V · 2026-05-25
I’m trying to set up a clean workflow between Paperclip and n8n, ideally with a simple HTTP adapter pattern. Has anyone here already built something similar? I’d like to keep the setup modular so it can later support other channels too. Any tips on the best architecture, webhook structure, or gotchas to avoid would be appreciated.
Answers
Aron Prins · 2026-05-25
Two patterns work cleanly for this — pick based on which side you want to "own" the agent loop.
Pattern A: n8n as the agent runtime (recommended for your modular-channel ask). Use Paperclip's http adapter ([docs/adapters/http.md](https://github.com/paperclipai/paperclip/blob/master/docs/adapters/http.md)). Each run POSTs to an n8n webhook with the fixed payload { runId, agentId, companyId, context: { taskId, wakeReason, commentId } }. Your n8n workflow takes it from there — branch on wakeReason and context.commentId, do the work, then call back to PAPERCLIPAPIURL (post a comment, mark complete, etc.) using an agent API key. One Paperclip agent per n8n workflow keeps it composable: a Slack workflow, a Discord workflow, an ops workflow all sit behind the same shape.
Pattern B: n8n as an outbound channel only. Keep your real agent on a local adapter (claudelocal / codexlocal / hermeslocal) and let it call into n8n via webhook nodes when it wants to fan out to channels. Simpler if you only need n8n for distribution.
Gotchas worth knowing up front:
The http adapter is fire-and-forget for stdout — you won't see real-time run transcripts in the Paperclip UI, only the final response body. If transcript visibility matters, log key steps as Paperclip comments from your n8n workflow so they show up on the issue. Always include an idempotency key when your n8n flow calls back. Re-deliveries on transient n8n hiccups will otherwise double-post. Treat wakeReason as the routing key — it tells you whether this is a scheduled tick, a comment reply, a task assignment, etc. Map it to n8n branches up front. For the multi-channel shape: one Paperclip agent per channel (each with its own n8n webhook URL) ages better than one agent that fan-outs internally. You get per-channel pause, per-channel heartbeat, per-channel auth boundary.
For a concrete starter you can read end-to-end, the scripts/smoke/openclaw-join.sh and scripts/smoke/openclaw-gateway-e2e.sh flows in the repo are the closest worked examples of a remote runtime claiming and completing Paperclip work over HTTP — same shape, different tool. Walking through those will give you the exact request/response sequence you'll want to mirror in n8n.