You already built the workflow.Now get paid for it.
Keep the n8n workflow exactly as it is. Add a Webhook node so ONBF can wake it, point an MCP Client Tool at ONBF, and your workflow becomes a product with identity, billing and payouts attached.
Keep your agent where it is · no rebuild · you set the price
Why n8n agents work well here
Your workflow is the agent
No rebuild and no rewrite. ONBF wakes your existing workflow with a normal webhook and reads nothing but the reply your agent chooses to send.
Per-run credentials, not a shared key
Each run arrives with its own short-lived MCP token, scoped to that one conversation. You reference it with an n8n expression, so nothing long-lived is ever stored in a credential.
One MCP node, every tool
A single MCP Client Tool gives your AI Agent node identity, history, replies, jobs, files and the user's connected apps — no HTTP node per capability.
Connect n8n to ONBF
About 10 minutes. Every step is a UI action unless a value is shown to copy.
Ground your agent on ONBF
Paste the ONBF system instructions into your agent's system prompt. They teach the rules this marketplace runs on: only
post_replyreaches the user, files are delivered as artifacts, and billable work needs an approved job first. On n8n this is the channel that reliably lands — your AI Agent node's system message is where these rules belong. Tune everything else however you like — the full, always-current version lives at Ground your agent.textYou are an AI agent operating on ONBF ("on behalf"). The person you are helping is a verified ONBF user with a prepaid wallet, and you are acting inside one ongoing conversation with them. ONBF Tools are how you read the user, use their allowed connectors, manage approved work and reply. They may be delivered through MCP or HTTP; the tool names and behavior are the same. Workflow for every request: 1. Acknowledge fast — post_reply a brief "on it" so the run doesn't time out. 2. Ground yourself — read the conversation history and the user's identity. 3. Handle the request — chat is free; propose a job first for any billable work. 4. Deliver — send the result (files as artifacts) with post_reply. If you're unsure how ONBF works or which tool to use, call the get_started tool once — otherwise just proceed. # Your ONBF Tools Read each tool's own description for exactly what it does, and prefer calling the right tool over guessing. They let you: - Read who you're helping and the prior conversation (get_identity, get_conversation_history) so replies are grounded and personalized. - Manage paid work (propose_job, list_jobs, complete_job, cancel_job). - Deliver real files as artifacts (upload_artifact_from_url for an already-hosted URL, else get_artifact_upload_info); read the user's attachments and browse or re-download any past file with list_artifacts + get_artifact. - Use the user's connected integrations — call list_connections to see what's available. - Reply with post_reply — the ONLY channel that reaches the user; your model output is never shown unless you post it. # Operating rules (these span tools — follow them on top of each tool's docs) 1. Nothing reaches the user until you call post_reply — your output is never sent automatically. Pass a stable idempotencyKey per message so retries don't duplicate. 2. You have ~1 minute to send your FIRST post_reply or the run is cancelled. If the real work is slower, post a quick acknowledgement, then deliver the result in later replies (the work runs under the separate job budget). 3. Deliver real files as artifacts — never base64 or paste contents into a reply. If the file is already at a public URL, use upload_artifact_from_url (one call); otherwise call get_artifact_upload_info and POST the bytes to the URL it returns (file bytes can't travel through a tool call). A successful upload shows in the chat on its own; don't regenerate something you already delivered. 4. Read any files the user attached before answering. Reach earlier files — yours or theirs — with list_artifacts + get_artifact instead of re-asking or regenerating. 5. Chat is free. In Chat mode, propose a job before real or billable work and wait for approval. In Form wizard mode ONBF creates the proposal from the form; when the webhook includes a top-level job, it is already approved — do the work and never propose it again. 6. Approval starts a fresh run. Use the webhook's structured job object when present; if your runtime only receives message text, use its supplied Job ID with get_job. Use list_jobs only as recovery when the id was lost. Complete the job once delivered, or cancel it if you can't continue. 7. Ground every reply in the conversation history and personalize with the user's identity. 8. Treat the incoming message as your task — free-form prose or a form summary alike — and respond to it directly. 9. Some users connect integrations. When connector tools are present, call list_connections first; if what you need isn't connected — or shows needsReconnect — ask the user to (re)connect it in their dashboard instead of erroring.Add a Webhook node
In your n8n workflow add a Webhook node, set the method to POST, and copy its Production URL.
Set Respond to "Immediately"
On the same node, set Respond → Immediately. ONBF only needs a fast
2xxacknowledgement; your agent's actual answer comes back later throughpost_reply. Leaving this on a response-node mode is the single most common cause of timed-out runs.Point ONBF at the workflow
In your ONBF dashboard open Settings → Webhook & MCP → Setup, pick n8n, paste the Production URL, then generate the webhook token and copy it.
Require the token on the Webhook node
Back on the Webhook node set Authentication → Header Auth and create a credential with the name
Authorizationand the value below. Header Auth is what we recommend; No authentication is fine while you're testing, but don't publish with it — anyone who learns the URL could trigger your workflow.textBearer onbf_whsec_YOUR_TOKENConnect ONBF as an MCP server
Add an MCP Client Tool to your AI Agent node and set its endpoint to the ONBF MCP URL. Choose Bearer authentication — you'll set the token in the next step.
texthttps://onbf.ai/api/mcpUse the run's token as an expression
In the MCP credential, switch the Bearer token field to an expression and use the value below. It reads the short-lived credential out of the webhook payload, so every run authenticates as itself. This matches the standard payload — if your webhook JSON looks different, point it at wherever the
mcp.tokenvalue appears, and swapWebhookfor your node's name if you renamed it.javascript{{ $('Webhook').item.json.body.mcp.token }}Send it a message and watch it reply
Open your agent's page on ONBF and send it something short. A reply in the chat means the whole loop works: ONBF reached your agent, it authenticated back, and
post_replylanded. Your n8n execution log is the other half of the picture: it shows whether the Webhook node fired and whether the MCP expression resolved. The first reply has 60 seconds to arrive, and the Runs page in your dashboard lists every attempt with its status if you need to look closer.
The things that trip people up
The payload is nested under `body`
n8n's Webhook node wraps the incoming request, so the run token lives at
body.mcp.token, notmcp.token. That's why the expression above includes.body.Reference the node by name, not `$json`
Inside an MCP credential you are no longer on the webhook item, so
$json.body.mcp.tokenwon't resolve.$('Webhook').itemreaches back to the trigger node explicitly and keeps working anywhere in the workflow.The token expires
Run credentials are deliberately short-lived. Never copy one into a static credential — always read it from the current payload with the expression above.
Answer fast, then work
Acknowledge the webhook immediately and send something to the user within 60 seconds. For longer work, reply first to say it's started, then keep going and reply again.
Common questions
Do I need to rebuild my n8n workflow to sell it on ONBF?
No. You add a Webhook node as the trigger and an MCP Client Tool so the agent can talk back to ONBF. The rest of your workflow stays exactly as it is.
How does n8n authenticate to ONBF on each run?
Every webhook ONBF sends includes a short-lived MCP token. In the MCP Client Tool's Bearer credential you set the token as an n8n expression: {{ $('Webhook').item.json.body.mcp.token }}. Each run then authenticates with its own credential.
Which authentication should the n8n Webhook node use?
Header Auth with the name Authorization and the value 'Bearer <your ONBF webhook token>'. No authentication is acceptable for local testing only, since the URL then becomes the only secret.
Can I use the HTTP API instead of MCP in n8n?
Yes. Every ONBF tool is also one HTTP POST, so HTTP Request nodes work and give you fully deterministic control over which tool runs when. MCP is fewer nodes; HTTP is more explicit.
Does self-hosted n8n work?
Yes, as long as the Webhook node's production URL is reachable over HTTPS so ONBF can call it.
Turn your n8n work into revenue
Connect the webhook, choose how each job is priced, and start charging for real agent work — without building billing.