Coder Legion - Recent posts tagged n8n

How Much Does It Cost to Automate Lead Follow-Up in the Philippines?

Sat, 31 Oct 2026 15:50:00 +0000

Most small businesses in the Philippines do not lose leads because the product is wrong. They lose leads because an inquiry arrives on Messenger, a website form, email, or a missed call, and nobody follows up before the customer moves on. Automating that follow-up is usually the first automation worth paying for.

Partner disclosure. This guide includes a partner link to n8n Cloud. If you sign up through it, I may earn a commission at no extra cost to you.

The natural next question is cost. The honest answer is that it ranges from free to a monthly subscription to a small server bill plus your time. This guide breaks down four realistic options, with prices converted to pesos, so you can match the cost to the size of your business.

Pricing note: software prices change often and depend on billing interval and tier. The figures below were checked in June 2026 against vendor pricing pages and converted at roughly ₱61 per US dollar. Exchange rates and plan prices move, so treat these as a planning range, not a quote, and confirm current pricing before you commit.

Option A: Free DIY with Google tools

If your lead volume is low and you are comfortable doing light setup yourself, you can build a basic follow-up system for ₱0 per month. A Google Form captures the inquiry, Google Sheets stores it, and Gmail sends the first reply or a reminder to yourself. No subscription, no code.

This is the right starting point for a solo operator, a sari-sari style online shop, or a service business getting its first few inquiries a week. It will not route leads by urgency or draft smart replies, but it makes sure nothing falls through the cracks. I wrote a full walkthrough of this approach in free business automation with Google Forms, Sheets, and Gmail.

Option B: Cloud no-code tools

When you outgrow manual steps, a cloud automation tool connects your form, your inbox, your spreadsheet or CRM, and a chat alert, and runs the follow-up automatically. The three common choices are Zapier, Make, and n8n Cloud. Rough starting prices, billed annually:

Make: from about ₱550/mo for the Core plan ($9/mo billed annually). Usually the cheapest entry point.
Zapier: from about ₱1,220/mo for the Starter plan ($19.99/mo billed annually). The simplest to set up.
n8n Cloud: from about ₱1,220/mo for the Starter plan ($20/mo billed annually), priced by workflow executions rather than per step.

These are the annual-billed headline prices. Monthly billing costs more, so a tool that looks cheap month to month can cost noticeably more if you do not commit to a year. The other thing to watch is how each tool counts usage: Zapier counts tasks, Make counts credits, and n8n counts executions. For a multi-step follow-up workflow, that difference changes the bill more than the headline price does. I compared this in detail in Zapier vs Make vs n8n pricing.

For a concrete example, the Facebook Lead Ads to Google Sheets and email guide shows how n8n can replace the Zapier layer for one common lead-capture path while keeping the spreadsheet and notification simple.

Option C: Self-hosted n8n on a VPS

Self-hosting n8n removes the monthly software subscription. The software is free, and a small VPS that can run it costs roughly ₱300 to ₱600 per month. On the invoice, this is the cheapest way to run unlimited workflows.

The invoice is not the full cost. Self-hosting moves the work to you. Someone has to handle:

Deployment: setting up the server, Docker, n8n, a database, HTTPS, and a domain. A first clean deploy can take a day or two if you have not done it before.
Updates: n8n releases often. Updating safely means reading release notes and testing that your workflows still run.
Backups: workflows, credentials, the database, and the encryption key all need to be backed up. Exporting a workflow JSON is not a backup.
Monitoring: if the server or a workflow goes down at 2am, you only find out if something is watching it.
Break-fix: when an integration changes or a credential expires, you are the support team.

None of this is hard once it is set up, but it is real ongoing time. For a business with someone technical in-house, self-hosting is excellent value. For a business without that, the ₱300 to ₱600 server bill can quietly turn into hours you did not budget. I documented a realistic build in self-hosted n8n deployment with Docker and Cloudflare.

Option D: Done for you

The last option is to have someone build the workflow, then either hand it over or keep it maintained. The cost here is a one-time build plus optional monthly upkeep. It is the right fit when the follow-up process matters to revenue and you would rather buy the result than learn the tools.

What you are really paying for is the design and the maintenance, not the software. A well-built lead workflow that captures the inquiry, saves it, alerts the right person, and tracks status is worth far more than the ₱550 tool bill underneath it.

The cost at a glance

For a typical small business automating lead follow-up, this is the rough shape of each option before any AI steps or heavy volume.

DIY free

₱0/mo

Google Forms + Sheets + Gmail

Best for solo operators and low lead volume. You do the setup, but nothing falls through the cracks.

Cloud no-code

from ~₱550/mo

Make, Zapier, or n8n Cloud

Best when you want reliable automation without running a server. Watch the usage model, not just the price.

Self-hosted n8n

~₱300-600/mo VPS

No subscription, plus your time

Cheapest invoice, but you own deployment, updates, backups, monitoring, and break-fix.

Done for you

build + optional retainer

Designed and maintained

Best when the follow-up process drives revenue and you want the result, not the tooling.

Prices are planning ranges checked in June 2026, converted at about ₱61 per US dollar. Exchange rates and plan prices change, so real cost depends on the current rate, billing interval, plan tier, lead volume, AI usage, and how much maintenance the workflow needs.

To turn these ranges into a payback number, the free automation ROI calculator estimates the hours and money a workflow would save and how quickly it earns back the build, so you can sanity-check whether any of these options is worth it for your lead volume.

Just starting: begin with the free Google tools setup. Prove the follow-up habit first, then automate more.
Steady inquiries, no technical staff: a cloud tool like Make or n8n Cloud is worth the monthly fee for the reliability.
Technical person in-house, many workflows: self-hosted n8n gives the best long-run value, as long as someone truly owns the upkeep.

One caveat before you spend anything on tooling: every option here assumes inquiries are already arriving. If too few people find you in the first place, no follow-up workflow will help, because there is nothing to follow up on. That is a visibility problem rather than an automation one, and the place to start is a fixed-price SEO audit.

A B2B company that also uses outbound prospecting has a separate upstream task: choosing accounts that can realistically buy before automating any follow-up. Use the B2B prospect list workflow to define the market and manually validate a small sample first.

The cheapest option is not always the right one. The right one is the system that actually gets built, runs reliably, and is easy enough to keep alive. A ₱550 tool that runs every day beats a free setup that nobody maintains.

Sources

n8n referral

Trying n8n Cloud?

If n8n looks like the right fit for your lead workflow, you can use my referral link. FloxoLab is an official n8n partner and may earn a commission at no extra cost to you.

Try n8n Cloud

Want a quick estimate for your leads?

Tell me where your leads come from and what happens after they arrive. I can map a lead follow-up workflow and estimate whether free tools, a cloud subscription, or self-hosted n8n fits your business best.

Get the map

Originally published on FloxoLab.

I Solved the Same Gmail Problem Two Ways Without Noticing

Thu, 29 Oct 2026 13:52:12 +0000

This is the third post from my n8n intake classifier, a practice project for a fictional automation agency that I built with an AI collaborator. The first was about the classification prompt. The second was about ambiguous, invalid and system_error. This one is about the wiring after classification: where logging goes, what the Gmail node does to your data, and a bug I only found by opening real inboxes. The workflow is in the GitHub repository.

A quick orientation: n8n is a workflow automation tool, and a workflow is built from nodes, each one a single step. The ones that matter here are Switch (sends an item down one of several paths), Set (reshapes the data) and Gmail (sends an email).

Where logging was supposed to go

After classification, a Switch node sends each submission down one of five paths, and each path sends emails. Every submission also gets logged to Google Sheets. For this phase I planned to work the way I had in the earlier ones: Sheets first, then emails, one branch at a time.

Before building anything, I caught a conflict. Logging is the same logic on all five paths, and only the data changes. Putting it first inside each branch meant five copies of one node, or converging after Sheets and then branching again to send category-specific emails. Neither made sense. So I flipped the order: build the emails first, since those differ per category, and let all five paths converge on one shared Sheets node at the end.

Gmail replaces your data

The first branch I built showed a second problem. When the Gmail node sends an email, the item it passes on is Gmail's own send confirmation, not the submission. Name, Email and description were gone by the time anything downstream needed them. The LLM Chain node had done the same thing to me earlier.

In the ambiguous/system_error branch, I added a Set node right after the internal notification to rebuild one clean object. The IF node and both client emails read from that, instead of each reaching back to whichever earlier node had the data. In simple_automation, I added a Set node after the client email to rebuild the object before it reached the shared Sheets node.

Noticing I'd solved it twice

While wiring the final Sheets node, I looked at the ambiguous/system_error branch and saw it fed Sheets from two points off the same rebuild node, one path through the client emails and one straight to Sheets. That wasn't a bug. The email path never reconnected to Sheets, so nothing was logged twice. But it showed me I had solved the Gmail problem two different ways. Everywhere else I rebuilt the data after the email. In this branch I branched before the email, because Sheets never needed anything the email step produced.

Moving logging upstream

That comparison pointed at something bigger. Every branch converged on one Sheets node, so there was no reason logging should depend on any email succeeding. A Gmail send can fail for reasons that have nothing to do with the submission.

I moved the Sheets connection to the two points right after classification: one for a successful classification and one for the failure handler. Both now feed the Switch and Sheets in parallel. Two side effects followed. has_partial_intent only had to be added in two places instead of four, and I could delete the end-of-branch Set nodes that existed only to feed the old Sheets wiring.

Before deleting any of them, I checked each one. Some still fed a client email's own data, and removing one of those would have broken a client-facing email without touching Sheets. I kept those.

The final build still contains both patterns. The ambiguous/system_error branch has its rebuild node, and the other client emails reach back to earlier nodes by name:

={{ $('Route: By Classification Category').item.json.Email }}

I haven't compared whether one pattern is more robust than the other. What changed is that logging no longer depends on either.

Checking real inboxes

After the rewiring, I retested every branch individually and checked real inboxes, not just node output. That caught a bug in the ai_workflow branch: the internal notification and the client email had their destinations swapped. The internal-only message went to the client, and the client's confirmation went to the team.

Both emails sent without errors, so nothing had failed that would make me suspect a problem. Only who received what showed it. I then confirmed the simple_automation branch had no swap, since I'd used the same inbox check there.

My notes don't record how the swap got there, or whether the rewiring caused it, so I won't guess. The current build sends each internal email to the team address and each client email to the submitter.

A test case I wrote wrong

While testing ambiguous, my first case was a deliberately vague description. It came back as invalid, and I took that as a bug. Reading the reasoning showed the classifier was right. Vague wording alone doesn't give any category a specific signal to rest on, which is a different situation from two categories each being concretely supported. I wrote a sharper case with explicit signals for both ai_workflow and custom_integration, and that one returned ambiguous.

What this doesn't show

Every test used descriptions I wrote. A forced classification failure does produce a row in the sheet, with the has_partial_intent cell empty, because the model never produced a value on that path. I did not test what happens if the Sheets step itself fails.

What I take from it is narrow: logging shouldn't wait on anything that can fail for unrelated reasons, and a branch that sends emails isn't tested until I've read the emails.

Ambiguous, Invalid, or System Error?

Thu, 22 Oct 2026 11:37:02 +0000

In my previous post, I wrote about the problems I found while defining the categories for an AI intake classifier. I left ambiguous and invalid for another post.

Those two states turned out to be only part of the problem. While wiring the workflow, I also needed to distinguish a request the model could not classify from a request the model never managed to evaluate.

This is the same practice project for a fictional automation agency, built in n8n with an AI collaborator. It is not a production client system. The workflow and project notes are in the GitHub repository.

Three different reasons for not choosing a project category

The classifier had three normal project categories:

simple_automation
custom_integration
ai_workflow

But not every submission should be forced into one of them.

ambiguous means the request is usable, but the text supports more than one category. The workflow should not pretend that a guess is a confident classification. In my sharper overlap test, I deliberately included concrete signals for both ai_workflow and custom_integration. The classifier returned ambiguous.

invalid means the input does not provide enough usable project intent to assign a normal category. This does not necessarily mean the person has no genuine request. A vague but relevant message can still contain partial intent. On the other hand, an out-of-scope message may contain nothing useful to route.

system_error means classification did not complete. The workflow did not reach a decision about the request, so treating it as invalid would report something the system did not know.

The difference matters because each state calls for a different response. A real request with overlapping categories may need a person to decide. An out-of-scope submission may not need a client email. A system failure needs troubleshooting or a retry, not a judgment about the request itself.

`invalid` needed one more field

My first definition of invalid treated missing information as the main signal. That overlapped with ambiguous, because both could describe a submission that could not be assigned cleanly. I changed the distinction: ambiguous is for multiple categories supported by the text; invalid is for input that does not support a responsible category assignment.

Then I noticed that one invalid label was still hiding two different situations:

The person has a real project in mind, but the request is too vague to classify yet.
The submission is unrelated or out of scope, with no useful project intent to follow up on.

I could have tried routing by keywords in the model's reasoning text, but that would make the workflow depend on the exact wording of an explanation. I also considered a conditional schema. Because the result passed through n8n's Structured Output Parser, I did not want to assume that conditional-schema behavior would be preserved through its translation layer.

I chose a simpler, always-present boolean: has_partial_intent.

{
  "category": "invalid",
  "has_partial_intent": true
}

That keeps invalid as the category and makes the next decision explicit. It is easier for a downstream node to route on a boolean than to interpret free-text reasoning.

I tested it with three small examples:

help automating my workflow returned has_partial_intent: true. The request was vague, but it did point to a real automation need.
fix my car returned false. It was a request, but not one this intake workflow was built to handle.
I love football also returned false as unrelated input.

These examples helped check the distinction I had defined. They are not a representative dataset, and they do not tell me how often the classifier would get this right with real submissions.

A model failure is not an invalid submission

I also needed system_error for cases where classification itself failed. A network interruption or a broken model credential should not make the workflow label a valid request as invalid. The system has not made a decision about the content at all.

I tested the failure path by temporarily breaking the Gemini credentials. The workflow retried classification three times at five-second intervals, then reached the fallback route for human review. I also checked that the original submission data remained available on that path.

The ambiguous and system_error routes shared some downstream handling, but I kept the category values separate. The reason for sending something to human review is important: in one case the model made a decision that needs human judgment; in the other, it did not complete the decision.

That distinction affected the client-facing message too. For a system failure, it would have been misleading to send the same confirmation as if a normal classification had succeeded. The workflow needed to acknowledge the issue without claiming the request was invalid.

Why I used explicit routing

I had considered using an AI Agent to choose how these outcomes should be handled. I did not need another model-driven decision, though. The possible states were already known, and the workflow's job was to route each one consistently.

I used explicit Switch and IF branches instead. That made the expected paths visible in the workflow and easier to test. For the invalid case with has_partial_intent: false, I confirmed that no email was sent while the submission was still logged to Google Sheets. Logging did not depend on sending a client message.

What I can claim from these tests

I exercised a deliberately ambiguous request, vague and out-of-scope inputs, and a forced model failure. I also checked the fallback path and verified that the invalid/no-partial-intent case was logged without triggering emails.

That is evidence that these particular paths were exercised in this build. It is not proof of general classifier accuracy or production reliability. The examples were written by me, and a larger, independently labelled set of realistic submissions would be needed to measure that properly.

The useful lesson for me was that a fallback is not just a place to send everything that does not match a normal category. The workflow needs to preserve why it did not choose a category: competing interpretations, insufficient or irrelevant intent, or a failure to classify at all.

How to Inspect an Agent Skill Before You Adopt It — with n8n and Agentel MCP

Mon, 19 Oct 2026 13:01:39 +0000

Before giving an Agent a new Skill, what can you actually check?

A description may sound promising, but it won't tell you everything you need to know. Which version is registered? What permissions are declared? Is there a license? What evidence backs up the listing?

We built a small, manual n8n workflow to make those details easier to inspect. It's now published in the n8n template library.

It also checks which Agentel Reader you're using, whether there's enough reading allowance for one detail request, and what the allowance looks like afterward.

No LLM, model API key or AI Agent node is needed. This is a regular, deterministic n8n workflow.

What the workflow does

Here's the path:

Run manually → Choose Skill → Connection before → Read budget
  → Can read one detail?
      true  → Skill detail → Inspect evidence → Connection after
            → Evidence and balance receipt
      false → Read not started

Three native MCP Client nodes call https://agentel.tech/mcp with the same restricted Reader credential. The two connection nodes call get_connection; the detail node calls get_network_item.

The result is a Skill record and an allowance receipt you can review. It doesn't install the Skill, run its code or grant it permissions. Those decisions are still yours.

What you'll need

An n8n editor you can administer, with the native MCP Client node and HTTP Streamable transport.
An Agentel INFO_READ restricted Reader credential.
Enough current reading allowance for one Skill detail request.

For context, the execution checks behind this tutorial were run on local n8n 2.42.4 / native MCP Client 1.1 on October 17, 2026. We haven't established the same results for n8n Cloud, other versions, independent customer environments or autonomous Agent tool selection. The template was approved for publication on October 19; that approval is not a certification of those other environments.

1. Import the template

Open the n8n template page and choose Use for free. You can select an import destination or use Copy template to clipboard (JSON) and paste it into a blank workflow canvas.

If clipboard import doesn't work, visit the Agentel n8n setup page, download agentel-skill-evidence.n8n.json, and use Import from File in n8n. That page also has a separate connection checker, bilingual instructions and a ZIP download.

Keep the workflow inactive and manual-only for this test. Don't add a schedule or automatic retries.

2. Create a read-only Reader credential

Follow the Agentel Reader setup guide.

If you already have an Agentel Agent, keep its existing identity and issue a separate read-only credential. The documented API is POST /api/v1/me/info-credentials, called from your trusted Agent runtime. Don't move your runtime credential into n8n.

If you don't have an Agent identity, the documented registration flow supports mode: "INFO_READER" to create a private Reader identity and credential. Use the current setup instructions rather than reusing somebody else's credential or creating duplicate identities.

In either case, n8n should receive only the restricted INFO_READ token—not an owner credential, full runtime key, Claim Code or Recovery Code.

3. Check workflow settings before connecting

One detail caught us during testing: settings for execution retention and timeout weren't preserved by a normal JSON import. So check them in the editor rather than trusting the file.

Open More actions → Settings and set:

Save failed production executions → Do not save
Save successful production executions → Do not save
Save manual executions → Do not save
Save execution progress → Do not save
Timeout Workflow → Enabled, 1 minute 30 seconds

Save, reopen Settings, and make sure the choices stuck.

These settings reduce saved execution payloads, but manual runs can still show identity and allowance in your browser. They also don't prove that metadata, logs or backups are erased; follow your own instance's retention policy.

4. Connect the three MCP nodes

Create a private Bearer Auth credential in n8n. Paste the restricted Reader token into the token field without typing Bearer in front of it; the credential adds that header itself.

Use these settings in every MCP Client node:

Setting	Value
Server transport	HTTP Streamable
MCP endpoint	`https://agentel.tech/mcp`
Authentication	Bearer Auth
Credential	Your restricted INFO_READ Reader

Bind the same credential to Connection before, Skill detail and Connection after. Check all three: n8n may auto-select an existing credential.

Avoid placing tokens in Code nodes, workflow parameters, sticky notes, URLs or screenshots. Also review exports before sharing them: n8n's export documentation notes that credential names and IDs can appear in exported workflows. Remove credential references and execution data from anything you share.

5. Check the connection

There's an optional connection-check workflow if you want to check the Reader before trying the main flow. Give it the same settings review and bind its Connection node to your restricted credential.

In our October 17 test, get_connection cost 0 INFO. Its current response can show the bound identity, read-only state, plan class and allowance.

CONNECTION_READY means the local connection and format checks passed. It doesn't mean a Skill has been installed or that every detail call fits within the remaining allowance. A Reader can have a valid connection with zero allowance left.

If the MCP node reports an authentication, transport, timeout or tool error, stop and check that error instead of automatically retrying.

6. Inspect one Skill

Back in the main workflow, open Choose Skill and set skill_id to the public Skill reference you want to inspect. The downloadable template defaults to agentel.

Leave the identity, pricing, allowance and failure checks in place, then run the workflow manually once.

The workflow checks the Reader's daily and monthly allowance before admitting at most one detail attempt. If the local checks don't allow the request, it follows Read not started and tells you why.

This preflight is not a reservation: current pricing, concurrent activity and allowance resets can affect what happens between the before/after checks.

7. Read the evidence, not just the green checkmark

Look at the registered version, declared permissions, license and evidence level. These fields are useful, but none is a runtime guarantee.

For example:

Unknown license means you still need to check the original source and terms.
Declared permissions tell you what's recorded, not what has been independently enforced.
source_checked means source checking was recorded. It does not mean the Skill was runtime-tested, independently verified or certified safe.

The workflow doesn't install or execute the Skill, approve its permissions, join a Mission, publish anything or award Credit.

The receipt also compares allowance before and after. In one October 17 run, a real Skill detail reported 1 INFO, and daily and monthly allowance each decreased by 1. That's an observation from that run, not a permanent price promise; a shared balance change alone also can't prove exclusive attribution.

INFO is Agentel plan allowance, not a separate card charge for each request. Check the current plan and allowance before running. Repeated attempts may consume allowance, including attempts that fail or have an unknown outcome.

If the receipt shows METERING_UNKNOWN, don't treat it as a free request. Changes in identity, metering subject, allowance limits or reset windows can make a before/after comparison unreliable. Investigate instead of automatically replaying it.

Troubleshooting

What happened	What to check
Clipboard says copied, but nothing pastes	Download the official JSON and use Import from File; recheck Settings.
Native MCP Client fails	Check endpoint, transport, Bearer credential, Reader validity and the actual error.
Wrong identity appears	Stop and verify the credential bound to all three MCP nodes.
Read not started	Look at the preflight reason, current price and both allowance windows.
Settings reverted	Reapply retention choices and the 90-second timeout, then save and reopen.
Green execution, missing evidence	Inspect the business result and required fields; a green node alone isn't proof.
`METERING_UNKNOWN`	Preserve the result privately and investigate before attempting another read.

Large or unusual responses may also affect what the client displays; this workflow hasn't established universal response compatibility.

Why use MCP for this?

The point isn't to make an Agent automatically trust another Agent's Skill. It's to give a person a practical way to inspect information from an external network before making a decision.

Here, n8n's native MCP Client runs tools as ordinary workflow steps. n8n has a separate MCP Client Tool node for AI Agent tool use. We tested the deterministic path, not autonomous Agent compatibility. The official n8n documentation explains the distinction.

Try it and tell us where it falls short

Start with the published workflow and keep the setup guide open as you go.

If you try it, I'm especially interested in what wasn't clear: Was setup harder than expected? Did the evidence help you decide anything? Was something important missing?

For troubleshooting, send your n8n version, MCP Client node version, import method, failing step and a redacted error code to the Agentel n8n Maintainer. Please leave out credentials, private identity details, balances and raw execution dumps. Even a first-time setup blocker is useful feedback.

Disclosure: Agentel provides this workflow and article, and operates the maintainer. n8n template-library approval confirms the published listing; it does not certify a Skill's safety or establish independent customer outcomes.

Escaping the Automation Tax: Migrating AI Agent Workflows to Self-Hosted n8n

Sun, 18 Oct 2026 10:52:53 +0000

⚡ TL;DR — Ready-to-Deploy Automation Blueprints:

🚀 Turnkey Production Package (This Guide): Instant Access on Whop | Download on Gumroad (Use code EARLYBIRD for -20%)

🎁 Free Starter Blueprints (0€): n8n AI Memory & Notion/Airtable RAG Sync | Programmatic SEO Engine (Python)

💎 MR Studio Lifetime All-Access Vault: Get All Current & Future Workflows (€39 One-Time)

If you’ve built AI agents on usage-based cloud automation platforms (like Zapier or Make), you already know the fatal flaw: success is penalized.

When you have an AI agent that scrapes a site, chunks the data, loops through an LLM to extract insights, and routes the formatted data to a CRM, you aren't executing one task. You are executing 15 to 50 tasks per run. At scale, paying per-execution cripples your margins.

The solution is migrating complex, stateful workflows to a self-hosted environment like n8n. But migrating often causes pipeline downtime and requires rebuilding execution logic from scratch.

In this guide, I’ll walk you through the architecture, code, and deployment strategies to migrate a webhook-to-database AI enrichment pipeline to self-hosted n8n without dropping a single payload.

1. The Bottleneck: Why Cloud Automation Fails AI Agents

Commercial solutions are fantastic for simple Trigger -> Action workflows. But AI workflows are rarely linear. They require:

Loops & Pagination: Processing large documents or paginated API responses.
State Management: Remembering context between retries if an LLM API times out.
High-Volume Webhooks: Catching inbound data from forms or scrapers at high concurrency.

When you run a 20-step AI workflow 5,000 times a month on a commercial cloud platform, you're paying for 100,000 tasks. On a $20/month cloud VPS running n8n, that exact same workload costs exactly $20.

2. The Architecture: Webhook-to-CRM Pipeline

To make this practical, let's architect a robust B2B Lead Enrichment Pipeline. The pipeline receives a raw email and company name, scrapes the company website, uses an LLM to determine the company's tech stack, and upserts it into a PostgreSQL database (or CRM).

The Flow:

Webhook Node: Catches the inbound POST request.
Code Node (JavaScript): Sanitizes the domain and validates the payload schema.
HTTP Node: Fetches the target company's homepage HTML.
Code Node (Python): Parses the HTML and structures the LLM prompt.
OpenAI / Advanced AI Node: Extracts the tech stack and outputs strict JSON.
PostgreSQL Node: Upserts the data based on the domain key.
Error Trigger Workflow: A global error handler that catches rate limits and queues retries.

3. The Code & Logic

One of n8n's superpowers is the Code Node, which allows you to run custom JavaScript or Python. Here is how we handle domain sanitization and prompt structuring.

Step 2: Payload Validation & Domain Sanitization (JavaScript)

Drop this into an n8n Code node to clean messy inbound webhook data before it hits your expensive scraping/LLM steps.

// n8n Code Node: Sanitize Domain
const items = $input.all();
const sanitizedItems = [];

for (const item of items) {
  let rawEmail = item.json.body.email || "";
  let rawWebsite = item.json.body.website || "";
  
  // Extract domain from email if website is missing
  let domain = rawWebsite;
  if (!domain && rawEmail.includes("@")) {
    domain = rawEmail.split("@")[1];
  }
  
  // Strip protocols and www
  if (domain) {
    domain = domain.replace("https://", "").replace("http://", "").replace("www.", "").split("/")[0];
  }

  if (!domain) {
    throw new Error("Validation Failed: No valid domain found.");
  }

  sanitizedItems.push({
    json: {
      ...item.json.body,
      clean_domain: domain
    }
  });
}

return sanitizedItems;

Step 4: Prompt Structuring (Python)

Using n8n's Python support, we can cleanly truncate the HTML and structure a deterministic prompt for the LLM.

# n8n Code Node (Python): Prepare LLM Payload
import re

def clean_html(raw_html):
    # Remove scripts and styles
    clean = re.sub('<script.*?</script>', '', raw_html, flags=re.DOTALL)
    clean = re.sub('<style.*?</style>', '', clean, flags=re.DOTALL)
    # Strip remaining tags
    clean = re.sub('<.*?>', ' ', clean)
    return ' '.join(clean.split())[:8000] # Truncate to fit context window

items = _input.all()
out = []

for item in items:
    html_content = item.json.get('html_data', '')
    cleaned_text = clean_html(html_content)
    
    system_prompt = "You are a B2B data extraction agent. Analyze the text and return a JSON object with 'tech_stack' (array) and 'industry' (string)."
    
    out.append({
        "json": {
            "system_prompt": system_prompt,
            "user_prompt": "Website Text: " + cleaned_text,
            "domain": item.json.get('clean_domain')
        }
    })

return out

4. Deployment & Performance: Handling the Chaos

When migrating to self-hosted n8n, you are now responsible for execution resilience. Here are the three non-negotiables for production AI workflows:

1. Built-in Retry Logic & Rate Limits
LLM providers rate-limit you. In your n8n HTTP or AI nodes, open the Settings tab.

Set On Error to Continue (using Error Output).
Use an If node to check for HTTP status 429 (Too Many Requests).
Route the error to a Wait Node set to delay for 60 seconds, then loop it back to the AI node.

2. Workflow Timeouts
Scraping and AI inference can take minutes. Go to your Workflow Settings and increase the Timeout limit to at least 15 minutes to prevent the workflow from being killed mid-generation.

3. Global Error Routing
Create a separate workflow starting with an Error Trigger node. If any node in your main pipeline hard-fails, this workflow catches the execution ID, the error trace, and the exact payload, alerting you via Slack or logging it in your database so no leads are dropped during migration.

5. Conclusion & Ready-to-use Workflow

Migrating from commercial cloud automation to self-hosted n8n is the single highest ROI engineering task you can do for your AI agent infrastructure. The cost scales asymptotically to zero, and you gain absolute control over your state, timeouts, and logic.

You can absolutely rebuild your infrastructure from scratch using the logic and code blocks above. However, if you want to skip the 20+ hours of debugging node configurations, writing regex, and testing error-handling loops, I've packaged my exact production setups.

The Cloud Automation to n8n Migration Kit: Self-Hosted AI Workflows includes:

5 Production-Ready n8n AI Agent Workflow Templates (JSON imports).
Drop-in replacements for complex webhook-to-database pipelines.
Pre-configured retry logic, rate-limit management, and error handling.
Plug-and-play JavaScript modules for n8n Code Nodes.

You can grab the turnkey package and import the JSON directly into your n8n instance today:

Instant Access on Whop: Get the Migration Kit Here
Direct Download on Gumroad: Download Here (Use promo code EARLYBIRD at checkout for 20% off).

Stop paying the automation tax. Self-host your agents, own your infrastructure, and scale your AI workflows without punishing your margins.

🛠️ D'autres outils MR Studio qui pourraient vous intéresser :

How I Built a Multi-Agent Micro-SaaS Orchestration Engine in n8n (Zero Cloud Subscriptions)

Sat, 17 Oct 2026 18:29:54 +0000

Building scalable, multi-agent AI systems usually means falling into one of two traps: drowning in the spaghetti code of Python-based orchestration libraries, or bleeding monthly recurring revenue to expensive, proprietary platforms like LangSmith or Vercel AI.

Managing prompt logic, token limits, and sub-agent handoffs across enterprise tools creates massive technical debt. You need a backend to handle agent orchestration, a database for context memory, and a frontend for your users.

In this guide, I’ll show you how to bypass the SaaS tax by building a Micro-SaaS Agent Farm & Sub-Agent Orchestration Engine entirely inside self-hosted n8n.

1. The Bottleneck: Why Commercial Solutions are Overpriced or Fragile

If you've tried deploying AutoGen or LangChain into production, you know they look great in Jupyter Notebooks but are a nightmare to scale.

Cloud Orchestration Costs: Enterprise orchestration platforms charge by the step or token, eating into your margins.
Frontend Friction: Building a custom React/Next.js dashboard just to trigger an agent workflow is overkill for an MVP.
Context Leaks: Relying on third-party APIs for memory management risks leaking proprietary user data and triggering compliance issues.

The solution is a Webhook-driven REST API sitting on top of an n8n Master/Worker architecture, hooked into a simple HTML/Tailwind frontend.

2. The Architecture: Master/Worker Sub-Agent Farm

We are shifting away from monolithic linear workflows to a distributed, parallel processing model.

Frontend (UI Component Library): A lightweight HTML/Tailwind form sends a standard POST request to our n8n webhook.
Master Agent (The Router): An n8n webhook receives the request, evaluates the user's intent, sanitizes the payload, and dynamically routes the task.
Worker Agents (The Farm): Independent n8n sub-workflows (e.g., Research Agent, Drafting Agent, Code QA Agent). These run in parallel via the "Execute Workflow" node.
Memory Manager: A self-hosted Postgres or Redis node that stores session IDs, keeping context zero-leak and strictly within your VPC.

This architecture allows you to deploy a Micro-SaaS instantly. Your UI just passes a JSON payload; n8n handles the heavy multi-agent lifting.

3. The Code & Logic: Handoffs and Sanitization

Domain Sanitization & Routing (JavaScript)

Before the Master Agent triggers a worker, we need to sanitize the input and determine the execution path. Here is the JavaScript logic for a Code Node in n8n that processes incoming webhook data:

// Master Agent Payload Sanitization & Routing Node
const payload = $input.item.json.body;
const rawPrompt = payload.user_prompt || "";

// Basic sanitization
const sanitizedPrompt = rawPrompt.replace(/[<>]/g, "").trim();

// Intent mapping based on keyword heuristics (or cheap LLM classification)
let targetWorker = "general_chat";
if (sanitizedPrompt.match(/research|find|scrape/i)) {
  targetWorker = "research_agent";
} else if (sanitizedPrompt.match(/code|debug|script/i)) {
  targetWorker = "code_agent";
}

return {
  session_id: payload.session_id || crypto.randomUUID(),
  worker: targetWorker,
  clean_prompt: sanitizedPrompt,
  timestamp: new Date().toISOString()
};

Context Structuring (Python)

To prevent context window overflow during sub-agent handoff, we use a Python node to chunk the conversation history before passing it to the Worker Agent's LLM.

# Python Node for Context Management
import json

def truncate_context(history, max_tokens=2000):
    # Rough estimation: 1 token ~= 4 characters
    max_chars = max_tokens * 4
    current_chars = 0
    truncated_history = []
    
    # Traverse history backwards to keep most recent context
    for msg in reversed(history):
        if current_chars + len(msg['content']) > max_chars:
            break
        truncated_history.insert(0, msg)
        current_chars += len(msg['content'])
        
    return truncated_history

# Assuming 'history' is passed from the previous n8n node
raw_history = _input.item.json.get("history", [])
optimized_context = truncate_context(raw_history)

return {"optimized_context": json.dumps(optimized_context)}

LLM Prompt Structuring

To ensure seamless handoffs, force the LLMs to output strict JSON using n8n's structured output settings.
System Prompt Example: You are the Research Sub-Agent. Analyze the context and return ONLY a valid JSON object with keys: {"findings": [], "confidence_score": 0.0, "requires_human": false}.

4. Deployment & Performance

Running a multi-agent farm requires careful orchestration to avoid server timeouts.

Handling Webhook Timeouts: Multi-agent workflows can take 30-60 seconds. Set your initial n8n webhook to "Respond Immediately" and return an HTTP 202 Accepted with a job_id. Your Tailwind frontend can then poll a second webhook (/status) using that job_id.
Rate Limits: When firing parallel worker agents to OpenAI or Anthropic, you'll hit rate limits quickly. Use n8n's Wait Node set to specific intervals between API calls, or route traffic through a load-balancing proxy.
CRM Routing: Once the final aggregator node compiles the workers' outputs, push the cleaned, structured data directly into HubSpot, Salesforce, or Airtable using native n8n credential blocks.

5. Conclusion & Ready-to-use Workflow

By decoupling the UI from the agentic backend and utilizing a Master/Worker sub-agent architecture in n8n, you can deploy infinitely scalable Micro-SaaS tools with zero cloud orchestration subscriptions. You own the code, you own the context, and you control the API costs.

You can manually recreate this entire system using the architecture and code snippets provided above.

However, if you want to skip the trial-and-error and instantly deploy this system to start generating revenue, I’ve packaged the complete n8n Micro-SaaS Agent Farm & Sub-Agent Orchestration Engine. It includes the production-ready n8n JSON blueprints, the reusable Tailwind/HTML frontend components, and the self-hosted memory schemas.

Grab the turnkey production-ready package here:

Instant Access on Whop: Get it here
Direct Download on Gumroad: Get it here (Use promo code EARLYBIRD at checkout for 20% off).

🛠️ D'autres outils MR Studio qui pourraient vous intéresser :

n8n Webhook Not Working? Test, Production, and 404 Fixes

Thu, 15 Oct 2026 15:50:00 +0000

An n8n webhook normally fails before the first workflow node runs. A 404 usually means the request did not match a registered webhook route. The common causes are a test URL with no active listener, a production URL for an unpublished workflow, the wrong HTTP method, a changed path, or an incorrect public URL on a self-hosted instance.

Partner disclosure. This guide includes a partner link to n8n Cloud. If you sign up through it, I may earn a commission at no extra cost to you.

Fastest check: open the Webhook node, copy the URL again, confirm whether it is Test or Production, and send the same HTTP method configured in the node. Do this before debugging credentials, expressions, or downstream nodes.

Start with the symptom

Symptom	Most likely check	First action
Test URL returns 404	No current test listener	Select Listen for test event, then resend within 120 seconds.
Production URL returns 404	Workflow is not published	Publish the workflow and copy the Production URL again.
URL works in a browser but not from the app	GET versus POST mismatch	Match the sender's method to the Webhook node.
URL has the wrong domain, port, or protocol	Self-hosted proxy configuration	Check `WEBHOOK_URL`, proxy hops, and forwarded headers.
Webhook runs but no data appears on the canvas	Production execution	Open the workflow's Executions tab.

Test URL versus Production URL

Every Webhook node exposes two URLs at the top of its panel. The official Webhook node documentation treats them as two different operating modes, not interchangeable copies of the same endpoint.

Use the Test URL while building

Select Test URL, then select Listen for test event before the external system sends its request. n8n registers the test webhook for 120 seconds and displays the incoming data in the editor. If the timer expires, register it again and resend the event.

Opening the workflow is not enough by itself. A saved test URL can return 404 later because test registration is temporary. This is useful during development because it lets one test payload appear directly on the canvas, but it is the wrong URL for a service that must call n8n at any time.

Use the Production URL after publishing

Select Production URL, copy it into the sending service, and Publish the workflow. Current n8n documentation uses Publish terminology. Publishing registers the production webhook and makes the published workflow version available to external requests until the workflow is unpublished.

Production payloads do not appear live on the editor canvas. Open Executions to confirm whether the request created a production execution and to inspect its input. No data on the canvas does not mean the webhook failed.

The n8n webhook 404 checklist

Run these checks in order. Stop as soon as the request reaches n8n.

Copy the URL from the node again. Do not rely on a URL saved in an old note, form, app, or API client.
Confirm Test or Production. Test requires a temporary listener. Production requires a published workflow.
Confirm the HTTP method. A POST request does not match a webhook registered only for GET.
Compare the path exactly. Check spelling, hyphens, route parameters, and any path changed after the sender was configured.
Check for a path-and-method conflict. n8n permits only one registered webhook for each path and method combination.
Inspect the public base URL. Do this only for self-hosted n8n behind a reverse proxy or when the node displays an internal hostname, HTTP instead of HTTPS, or the wrong port.

Check the HTTP method before the payload

The Webhook node supports GET, POST, PUT, PATCH, DELETE, and HEAD. By default it accepts one method. The sender must use that exact method. Pasting a webhook URL into a browser sends GET, so a successful browser test does not prove that a service's POST request will match, and the reverse is also true.

Current n8n versions can allow multiple HTTP methods from the node's Settings. Use that only when the endpoint genuinely needs more than one method. A tighter single-method webhook is easier to reason about and reduces accidental calls.

Check the webhook path

n8n generates a random path by default, and you can replace it with a stable custom path. Once an external app stores the URL, changing the Path field changes the route it must call. Copy the complete URL after every path change instead of editing only the last segment by hand.

n8n also requires each registered path and HTTP method combination to be unique. If another published workflow already owns the same combination, unpublish the conflicting workflow or choose a different path or method. The Webhook common-issues page documents both method matching and route conflicts.

Send a minimal request

Remove the external app from the diagnosis. Copy the exact URL from the Webhook node and test it with a safe placeholder payload. The example below uses POST. Change the method if your node uses something else.

curl --request POST 'https://n8n.example.com/webhook/example-path' \
  --header 'Content-Type: application/json' \
  --data '{"event":"webhook-test","id":"demo-001"}'

Replace the example URL with the full Test or Production URL copied from your node. For a Test URL, select Listen for test event immediately before running the command. For a Production URL, publish first. If this request works, the remaining problem is in the external app's stored URL, method, headers, authentication, or network access.

Reverse proxy and public URL problems

Skip this section on n8n Cloud. It matters when a self-hosted instance runs internally on one address but a reverse proxy exposes a different public HTTPS address.

n8n normally builds webhook URLs from N8N_PROTOCOL, N8N_HOST, and N8N_PORT. Behind a proxy, that can produce an internal port or the wrong scheme. The official reverse-proxy configuration says to set the public URL explicitly with WEBHOOK_URL, set N8N_PROXY_HOPS to the number of reverse proxies, and pass the forwarded host, protocol, and client information from the last proxy.

WEBHOOK_URL=https://n8n.example.com/
N8N_PROXY_HOPS=1

Do not copy this blindly. Use your real public HTTPS base URL and the actual number of proxies in the request path. Restart or redeploy n8n after changing environment variables, then copy the regenerated webhook URL from the node.

What to log before handing the webhook into production

The final Production URL location and which external system owns it. Do not paste secret query parameters into a public document.
The expected HTTP method, content type, authentication method, and a sanitized example payload.
The workflow owner and where production executions are reviewed.
The expected success response and what the sender does when it receives a non-2xx response.
The alert channel and recovery owner for failures after the webhook starts the workflow.

Once the route works, broader failures belong in the n8n workflow debugging guide. Production ownership and notifications belong in the n8n error workflow alerts guide. Keeping those jobs separate makes the webhook checklist short enough to use during an incident.

The production handoff

Test with the Test URL and one sanitized payload.
Switch the node to Production URL and copy the full value.
Publish the workflow.
Update the external service with the Production URL and matching method.
Trigger one real but safe event.
Confirm the run in Executions and record who owns failures.

n8n autosaves edits, but saved draft changes are not the same as the published version used by production executions. The save and publish documentation explains that production runs continue to use the current published version until you publish newer changes.

n8n referral

Want managed webhooks without maintaining the server?

I may earn a commission if you sign up through this link, at no extra cost to you.

Try n8n Cloud

Webhook still not reaching n8n?

Send the sanitized response, URL mode, HTTP method, and hosting setup. I will help narrow the failure to registration, routing, proxy configuration, or the sender.

Get help

Originally published on FloxoLab.

Each Fix to My Classification Prompt Exposed the Next Problem

Thu, 15 Oct 2026 14:01:19 +0000

This comes from my first n8n project with an LLM in it: an intake classifier for an automation agency. It's a practice brief, so the agency and the client are fictional, and I built it with an AI collaborator. The workflow and my full process notes are in the GitHub repo.

A client fills in a form, Gemini reads the project description through a Basic LLM Chain with a structured output parser (which forces the model to answer in a fixed JSON shape), and the submission gets sorted into a category that decides which emails go out and what gets logged to Google Sheets. This post is only about the classification prompt, and about a handful of test descriptions that kept sending me back into it.

Where it started

Three of the five categories are real project types: simple_automation, ai_workflow and custom_integration. The other two, ambiguous and invalid, are for submissions that don't sort cleanly. I'm leaving those for another post.

My first definition of simple_automation allowed exactly one action off a trigger. That seemed reasonable until I tested it with a description I'd picked as the easiest case:

when a client submits the form on my website, notify me and log it to a sheet

It came back ambiguous. Notifying me and logging to a sheet is two actions, and my definition only allowed one.

Problem 1: I'd defined the category by counting

Raising the limit to two actions would have been a patch. The real problem was that counting actions doesn't separate the three categories at all. What separates them is whether there's conditional logic, whether data is actually transformed, and whether AI reasoning is involved. I rewrote all three definitions around those, and the simple_automation one now says so directly:

simple_automation: One or more actions fire in a fixed, uniform way off a
single trigger. [...] No conditional branching (no "if X then Y, else Z"),
no computed or derived values, and no AI/LLM reasoning involved. The number
of destinations touched does not matter [...]

Problem 2: the model had to commit before it could compare

The next test was "route incoming leads smartly based on their details". I read the reasoning field on that one, and it said it saw two valid readings and picked one anyway.

Working out why, I realized it was my prompt's doing. It evaluated the categories in sequence, so the model had to commit to one before it ever checked whether another also fit. Genuine overlaps were being settled by the model's best guess instead of reaching ambiguous. I rebuilt the evaluation so each category is assessed independently and the model counts how many plausibly fit:

Do not decide sequentially. Instead:
[...]
3. Count how many categories plausibly fit:
   - Exactly one fits -> assign that category.
   - Two or more fit, and the description does not specify enough to pick
     between them -> assign 'ambiguous'.

I also added a line to the prompt saying that "more common in practice" is a guess about unstated intent, which is exactly what ambiguous exists to catch.

Problem 3: the schema asked for the answer before the reasoning

My schema also listed category before reasoning, so the model was structurally being asked for its answer before it had written the explanation that was supposed to inform it. I swapped them:

{
  "type": "object",
  "properties": {
    "reasoning": { "type": "string" },
    "category": {
      "type": "string",
      "enum": ["simple_automation", "ai_workflow", "custom_integration", "ambiguous", "invalid"]
    }
  },
  "required": ["reasoning", "category"]
}

(Trimmed to the two fields that matter here.) I changed the order and kept testing. I have no record of testing that change by itself, so I can't say how much of the later improvement comes from it.

Problem 4: the fix overcorrected

With the new wording, the model started treating "automatically" as a possible AI signal. That word just means "not manual", and it appears in nearly every automation request, so it would push ordinary requests toward ambiguous.

I tightened the definitions so each category only counts as plausible if the text contains a specific word or phrase that grounds it, and I named "automatically" and similar words as things that don't count. I also added a rule aimed at the habit I'd just watched:

If you find yourself justifying a category with "could imply" or "might
involve" without pointing to a specific word or phrase that drove that
reading, do not count it

Cleaning up

The old [TIE-BREAKING] section was still in the prompt. After the evaluation rewrite it repeated the same logic less precisely, so I removed it and reran both the original failing case and a genuinely ambiguous one to confirm each landed where it should.

Checking the boundaries

I wrote two more tests aimed at the seams between categories instead of one category at a time.

The first stacked signals on purpose: conditional branching ("if it's not feedback, stop"), several systems (Gmail, a data table, Slack), and clear AI work (sentiment extraction, summarizing, drafting a reply). The reasoning field weighed the branching signals against the AI ones and landed on ai_workflow, using my rule that custom_integration applies when the logic is driven by fixed rules, not AI reasoning. That rule is my call. A description with both could reasonably be argued the other way, so the result shows the prompt follows my rule, not that the rule is correct.

The second was the opposite check: budget-based lead routing across HubSpot, Slack and Mailchimp, with no AI language at all. I wanted to see whether multi-system complexity alone would get pulled into ai_workflow. It came back custom_integration, with the reasoning ruling out both other categories using the exclusion wording.

What this doesn't show

Every test above is a single description I wrote myself. That was enough to find four problems in the prompt, and not enough to say the prompt is reliable. A real set of varied inputs is the next thing it needs.

How I Built an OTel-Native GPU Profiler & LLM Gateway to Stop Bleeding Inference Costs

Wed, 14 Oct 2026 17:54:04 +0000

Running LLM workloads at scale—especially when integrating custom AI agents into n8n automation pipelines—creates a massive infrastructure blind spot. You build a brilliant workflow, fire thousands of requests, and suddenly your cloud bill skyrockets because of opaque GPU utilization and runaway inference costs.

Traditional cloud monitoring lacks granular, step-by-step visibility into CUDA kernel execution and per-token generation costs. As a result, engineering teams over-provision expensive hardware.

In this guide, I'll show you how to build an OTel-Native GPU Profiler & LLM Cost Optimization Gateway. We will use this async middleware to sit between an n8n lead enrichment pipeline and your custom AI backend, tracking real-time CUDA memory, calculating per-token inference costs, and exporting metrics natively to Prometheus and Grafana.

1. The Bottleneck: Why commercial solutions are overpriced or fragile

When scaling autonomous workflows (like scraping domains and analyzing them with an LLM to route to a CRM), you quickly hit bottlenecks. Commercial LLM observability tools (like Datadog or New Relic) charge a premium for AI APMs, and they often fail to capture deep hardware-level metrics like live VRAM allocation or step-latency inside PyTorch/vLLM.

If you don't know exactly how many tokens a specific prompt consumes, or how much CUDA memory spikes during a batched request, you end up renting an A100 when an L4 would have sufficed. The solution is an OpenTelemetry (OTel) native metric export running as a drop-in async middleware gateway.

2. The Architecture: Step-by-step breakdown of how the pipeline works

To bridge the gap between n8n's automation logic and raw GPU compute, the architecture is split into three layers:

The Orchestrator (n8n): Pulls raw lead data, triggers the HTTP request to our Gateway, and handles the final CRM routing.
The Async Gateway (FastAPI + OTel): Receives the payload, sanitizes the domain, structures the LLM prompt, and records real-time hardware telemetry.
The Observability Stack: The gateway exports OpenTelemetry metrics directly to a Prometheus scraper, visualized via Grafana.

Instead of n8n talking directly to OpenAI or a bare-metal HuggingFace endpoint, it talks to our Gateway. The Gateway wraps the inference call in an OTel trace, profiles the CUDA GPU, calculates the exact dollar cost of the run, and returns both the inference result and the cost metadata.

3. The Code & Logic: Domain sanitization, LLM prompt structuring, and OTel Metrics

Let's look at the core of the drop-in async middleware gateway. We need to handle the incoming request, sanitize the input data, structure the prompt, and most importantly, profile the GPU.

import time
import torch
from fastapi import FastAPI, Request
from opentelemetry import trace, metrics
from pydantic import BaseModel
from urllib.parse import urlparse

app = FastAPI()

# Initialize OTel Tracer and Meter
tracer = trace.get_tracer(__name__)
meter = metrics.get_meter(__name__)
cost_counter = meter.create_counter("llm.inference.cost", description="Calculated inference cost in USD")
vram_gauge = meter.create_gauge("gpu.cuda.vram_allocated", description="Current VRAM allocated in bytes")

class LeadPayload(BaseModel):
    raw_url: str
    company_name: str

def sanitize_domain(raw_url: str) -> str:
    """Strips UTMs, paths, and protocols to extract the clean root domain."""
    parsed = urlparse(raw_url if "//" in raw_url else f"http://{raw_url}")
    domain = parsed.netloc.replace("www.", "")
    return domain

def build_prompt(domain: str, company: str) -> str:
    """Structures a strict system prompt to prevent LLM hallucinations."""
    return f"""
    System: You are an expert B2B data extraction agent.
    Task: Analyze the company '{company}' at domain '{domain}'.
    Output strict JSON with fields: 'industry', 'employee_estimate', 'tech_stack'.
    """

@app.post("/api/v1/enrich-lead")
async def enrich_lead(payload: LeadPayload):
    with tracer.start_as_current_span("enrich_lead_pipeline") as span:
        # 1. Domain Sanitization
        clean_domain = sanitize_domain(payload.raw_url)
        prompt = build_prompt(clean_domain, payload.company_name)
        
        # 2. Pre-Inference GPU Profiling
        if torch.cuda.is_available():
            vram_before = torch.cuda.memory_allocated()
            vram_gauge.set(vram_before)
            span.set_attribute("gpu.vram.before", vram_before)

        # 3. Step-latency profiling for LLM execution
        start_time = time.time()
        
        # Mocking the async LLM call (Replace with vLLM/Transformers logic)
        response_data, tokens_used = await run_local_inference(prompt)
        
        latency = time.time() - start_time
        span.set_attribute("llm.latency_seconds", latency)
        
        # 4. Per-token inference cost calculation ($0.0002 per 1k tokens)
        calculated_cost = (tokens_used / 1000) * 0.0002
        cost_counter.add(calculated_cost)
        span.set_attribute("llm.cost_usd", calculated_cost)

        # 5. Post-Inference VRAM check
        if torch.cuda.is_available():
            vram_after = torch.cuda.memory_allocated()
            vram_gauge.set(vram_after)
            span.set_attribute("gpu.vram.after", vram_after)

        return {
            "enriched_data": response_data,
            "profiling": {
                "cost_usd": calculated_cost,
                "latency": latency,
                "tokens": tokens_used
            }
        }

By injecting this logic into the middleware, every single lead enrichment run outputs granular OTel data natively formatted for your Prometheus and Grafana dashboards.

4. Deployment & Performance: Timeouts, Rate Limits, and CRM Routing

Running a local LLM gateway means you are now responsible for the hardware lifecycle. Here is how to handle the critical deployment factors:

Timeout Management: In n8n, set the HTTP Request node timeout to at least 45 seconds to account for cold-start latency or massive prompt token generation. In your Python Gateway, utilize asyncio.wait_for to ensure requests don't hang indefinitely and lock up your VRAM.
Rate Limiting: GPUs queue up fast. Use a tool like Redis with FastAPI's SlowAPI to rate-limit incoming requests from n8n. If n8n attempts to push 500 leads simultaneously, the Gateway should return a 429 Too Many Requests. Configure n8n's "Retry on Fail" settings to use an exponential backoff.
CRM Routing: Once the Gateway responds with the enriched_data, n8n receives the sanitized JSON. You can then use a Switch node in n8n: if the industry is "Software" and the cost was under $0.01, route it immediately to the Salesforce/HubSpot node. If not, append it to a Google Sheet for manual review.

5. Conclusion & Ready-to-use Workflow

You no longer have an excuse for opaque LLM costs. By implementing an OTel-native Gateway, you get real-time CUDA memory tracking, compute utilization metrics, and per-token cost calculations without locking into expensive enterprise APMs.

You can take the code blocks above, integrate them into your FastApi/n8n stack, and build this entire pipeline yourself.

However, if you want to skip the trial-and-error of configuring Prometheus endpoints, writing the Grafana dashboard JSON, and setting up the async chunking logic, I've packaged the entire production-ready system.

Get the complete turnkey package, including test fixtures, n8n workflow JSON, and the full Gateway source code:

Instant Access on Whop: OTel-Native GPU Profiler & LLM Cost Optimization Gateway
Direct Download on Gumroad: Grab the Zip File here — use promo code EARLYBIRD for 20% off.

Stop over-provisioning your GPUs and start optimizing your autonomous pipelines today.

🛠️ D'autres outils MR Studio qui pourraient vous intéresser :

Retry Failed n8n API Requests Without Duplicates

Wed, 14 Oct 2026 15:50:00 +0000

The safe n8n retry pattern is simple: create one stable idempotency key for the business operation, send the same key and payload on every attempt, retry only temporary failures, and store the confirmed result. Turning on Retry On Fail without that protection can repeat a successful side effect when the first response was lost.

Partner disclosure. This guide includes a partner link to n8n Cloud. If you sign up through it, I may earn a commission at no extra cost to you.

The dangerous case: an API creates the order, but the connection closes before n8n receives the response. n8n sees a timeout. A second POST with a new key can create a second order even though the first request actually worked.

Decide whether the request is safe to repeat

HTTP defines GET, HEAD, OPTIONS, and TRACE as safe methods. PUT, DELETE, and the safe methods are idempotent by their intended semantics. POST is not automatically idempotent. The HTTP specification therefore says a client should not automatically retry a non-idempotent request unless it knows the operation is idempotent or can prove the first request was not applied.

Real APIs add their own rules, so the provider's documentation remains the contract. A DELETE endpoint may be harmless to repeat, while a POST that sends an email, creates a payment, or reserves stock needs explicit duplicate protection.

Failure	Default action	Duplicate risk
Network timeout or reset	Retry the identical request with the same operation key	High, because the remote service may already have committed the action
429 Too Many Requests	Wait for the provider's limit window, then retry	Controlled only if the operation remains idempotent
500, 502, 503, or 504	Use a small bounded retry policy when the provider permits it	Potentially high for state-changing requests
400, 401, 403, or most 404s	Fix the request, credentials, permission, or resource first	Blind retries add load but rarely fix the cause
409 Conflict	Inspect the API-specific error before deciding	May indicate an existing operation or key conflict

Step 1: create one key for one business operation

Build the key before the HTTP Request node from an ID that already belongs to the event: an order ID, checkout ID, lead ID, invoice ID, or source event ID. Include the action name so different operations on the same record cannot collide.

={{ 'create-order:' + $json.orderId }}

Keep this value unchanged across automatic node retries, manual execution retries, and later recovery runs. Do not use $now, the execution ID, or a freshly generated random value on each attempt. Those identify the attempt, not the operation, so the destination sees every retry as new work.

The key must also stay paired with the same endpoint and payload. If you correct the amount, recipient, or other business data, treat that as a deliberate new operation according to the provider's rules.

Step 2: use the API's idempotency feature first

If the destination API supports idempotency, send the stable key in the exact header or field its documentation specifies. Stripe, for example, accepts an Idempotency-Key header for POST requests and returns the stored result when the same request is repeated with the same key. That header name is not universal. Some APIs use a request ID, client reference, deduplication ID, or a provider-specific field.

Open the HTTP Request node and add the provider's documented idempotency header.
Map the stable operation key as its value.
Keep the method, URL, and request body identical on every retry.
Save the external object ID from the confirmed response for later reconciliation.

Do not assume: adding an Idempotency-Key header only works when the destination implements that contract. An unknown header may simply be ignored.

Step 3: configure a bounded n8n retry

Every n8n node has a Retry On Fail setting. When enabled, n8n reruns the node after a failure until it succeeds or reaches the configured attempt limit. For a known transient endpoint, start with a small policy such as three tries and a short wait between tries. Increase it only when the provider's limit and incident behavior justify the extra traffic.

This built-in setting is best when every error produced by that node is safe to retry. If you need status-aware behavior, enable Include Response Headers and Status and Never Error in the HTTP Request node. The node can then pass the status code and headers to an IF or Switch branch instead of stopping on every non-2xx response.

Send 2xx responses to the success branch.
Send 429 and approved temporary 5xx responses to a Wait step and bounded retry path.
Send authentication, validation, permission, and unexpected responses to a review or alert branch.
Stop after the maximum attempt count. Never create an unbounded loop.

Step 4: slow down 429 retries

A 429 response means the client sent too many requests in the provider's current limit window. Some APIs include Retry-After as seconds or an HTTP date. Read and honor it when the provider documents that behavior. If the header is absent, use the API's published limit and increase the delay between attempts rather than retrying immediately.

The HTTP Request node also has Items per Batch and Batch Interval options. They control how many input items are sent in each batch and how many milliseconds n8n waits between batches. Use them to prevent a known burst from creating the 429 in the first place.

Step 5: add a persistent duplicate check when needed

When the API has no idempotency feature, keep a small request ledger. n8n's Data Table node can check whether a row exists, insert rows, update them, and upsert by conditions. A practical table uses these columns:

Column	Purpose
`request_key`	Stable ID for the business operation
`status`	`pending`, `succeeded`, `failed`, or `unknown`
`external_id`	ID returned by the destination when available
`updated_at`	Timestamp for recovery and stale-pending review

Check for a row with the request key.
If it already says succeeded, return the stored result and skip the API call.
If no row exists, record pending, then call the API.
On a confirmed 2xx response, update the row to succeeded and store the external ID.
On a timeout, keep the state as unknown until you query the destination or retry safely.

This ledger is useful for sequential or low-concurrency workflows, but a check followed by an insert is not an atomic lock. Two executions can check at the same moment and both see no row. For parallel production traffic, prefer destination-side idempotency or a database table with a unique constraint on request_key and an atomic claim operation.

That pattern protects one API operation from replay. When the business problem is recognizing the same person across forms, email, phone, and an existing CRM, use the separate n8n lead deduplication workflow and its conflict-review path.

Do not use workflow static data as a production lock

The $getWorkflowStaticData() helper looks convenient for storing processed IDs, but n8n labels it experimental, says the data should be small, and warns that it may behave unreliably under high-frequency executions. That makes it unsuitable as the main duplicate barrier for valuable orders, payments, leads, or outbound messages.

A production-safe request sequence

Validate that the event contains a stable source ID.
Create the operation key once.
Check any local success record.
Send the request with the provider's idempotency mechanism.
Retry only network failures, 429s, and provider-approved temporary errors.
Reuse the same key and payload for every attempt.
Store the external ID after confirmed success.
Route exhausted or uncertain outcomes to an Error Workflow or manual review queue.

Keep request-level recovery separate from broad diagnosis. If you do not yet know why the node failed, use the failed n8n workflow debugging guide. Once the retry budget is exhausted, use an n8n Error Workflow to send the failure to Telegram, Slack, Google Chat, email, or another incident channel.

Common questions

Does Retry On Fail prevent duplicates in n8n?

No. It repeats the failed node. Duplicate prevention comes from idempotent request semantics, a provider-supported operation key, or a persistent store that can claim each business operation exactly once.

Should I retry every 500 response?

Not automatically. A 500 can leave a state-changing operation with an uncertain outcome. Follow the provider's error guidance, keep the same idempotency key, use a bounded retry policy, and reconcile the remote record when the result remains unknown.

Can the Remove Duplicates node replace an idempotency key?

It can remove repeated input items, but it cannot prove that a remote API did or did not apply an earlier request after a timeout. Protect the side effect at the API or persistence layer.

Sources checked

n8n partner link

Want managed n8n for the workflow?

I may earn a commission if you sign up through this link, at no extra cost to you.

Try n8n Cloud

Need one risky API workflow mapped?

Send the API operation, failure response, source ID, and expected business outcome. I will help separate safe retries from duplicate risk.

Map the retry path

Originally published on FloxoLab.

Building a Self-Healing, Type-Safe Desktop RPA with Python and Computer Vision

Wed, 14 Oct 2026 10:48:41 +0000

Desktop automation has a dirty secret: it’s terrifyingly brittle. If you’ve ever written a script that relies on static X/Y coordinates, you know the pain. A Windows update changes a button's padding by 5 pixels, a user moves a window, or UI scaling shifts—and suddenly your bot is blindly clicking empty space.

Enterprise RPA platforms (UiPath, Automation Anywhere) solve this, but they charge extortionate licensing fees just to access basic computer vision capabilities. You shouldn't have to pay massive corporate subscriptions for your script to "see" what's on the screen.

Today, we are going to build a resilient, local, type-safe automation engine that executes workflows based on visual state and OCR, completely free of corporate bloat.

1. The Bottleneck: Why commercial solutions are overpriced or fragile

When dealing with legacy desktop applications or Citrix environments where there is no DOM to inspect, developers usually resort to two terrible options:

Blind Coordinate Clicking: pyautogui.click(x=100, y=200). This breaks the second a window is resized.
Enterprise RPA: Heavily bloated, vendor-locked IDEs that cost thousands per seat and require a PhD in their proprietary visual languages.

The alternative? A lightweight, Python-based pipeline utilizing Computer Vision (OpenCV) and OCR (Tesseract/LLMs) to dynamically detect UI elements, combined with strict type-safe bindings (Pydantic) to ensure our workflows only execute when the application is in the exact expected state.

2. The Architecture: Visual State Detection

Instead of defining "where" an element is, we define "what" the screen should look like.

Our architecture consists of three layers:

The Vision Engine: Continuously captures screen buffers and runs fast localized OCR to find anchor text (e.g., "Submit", "Invoice Number").
The Type-Safe State Machine: Uses Pydantic to validate the parsed UI data. If the OCR reads a messy string, we run domain sanitization and pass it through a local LLM to map it strictly to our data model.
The Orchestrator (n8n): Acts as the brain, triggering the Python RPA agent via local webhooks and routing the structured data to our CRM.

3. The Code & Logic: Type-Safe Detection and LLM Sanitization

Here is the core logic. First, we define our expected UI state using Pydantic. Then, we use a combination of OCR and a lightweight LLM prompt to sanitize the messy text read from the screen (e.g., extracting clean domains and email addresses from a messy desktop email client).

import cv2
import pytesseract
import pyautogui
from pydantic import BaseModel, Field, ValidationError
from typing import Optional
import openai

# 1. Type-Safe Definition of our expected UI State
class InvoiceUIState(BaseModel):
    is_loaded: bool
    invoice_number: Optional[str] = Field(None, description="Extracted Invoice ID")
    client_domain: Optional[str] = Field(None, description="Sanitized client domain")

# 2. Domain Sanitization & LLM Prompt Structuring
def sanitize_ocr_with_llm(raw_ocr_text: str) -> InvoiceUIState:
    """Uses a local or fast API LLM to extract structured data from messy OCR."""
    prompt = f"""
    You are a data extraction agent. Parse the following raw OCR text from a desktop application.
    Extract the invoice number and sanitize the client's email into a clean domain.
    If the UI hasn't fully loaded, set is_loaded to false.
    
    Raw OCR:
    {raw_ocr_text}
    """
    
    # Using OpenAI's structured outputs to guarantee our Pydantic model
    response = openai.ChatCompletion.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": prompt}],
        functions=[{"name": "extract_ui", "parameters": InvoiceUIState.schema()}],
        function_call={"name": "extract_ui"}
    )
    
    return InvoiceUIState.parse_raw(response.choices[0].message.function_call.arguments)

# 3. Execution Logic
def click_element_by_text(target_text: str):
    """Finds screen coordinates dynamically based on OCR, avoiding X/Y brittleness."""
    screenshot = pyautogui.screenshot()
    screenshot.save("buffer.png")
    
    img = cv2.imread("buffer.png")
    data = pytesseract.image_to_data(img, output_type=pytesseract.Output.DICT)
    
    for i in range(len(data['text'])):
        if target_text.lower() in data['text'][i].lower():
            x, y, w, h = data['left'][i], data['top'][i], data['width'][i], data['height'][i]
            # Self-healing click: always targets the center of the found text
            pyautogui.click(x + w/2, y + h/2)
            return True
    raise Exception(f"Element '{target_text}' not found in current UI state.")

4. Deployment & Performance: Handling UI Rendering and Routing

When running this in production, desktop applications don't load instantly. We must implement Exponential Backoff to handle timeouts, rate limits, and rendering delays.

Instead of time.sleep(5) (which is an anti-pattern), wrap your vision checks in a polling loop:

import time

def wait_for_ui_state(target_text: str, timeout: int = 30):
    start_time = time.time()
    while time.time() - start_time < timeout:
        try:
            if click_element_by_text(target_text):
                print(f"UI State matched: {target_text}")
                return
        except Exception:
            time.sleep(1) # Wait 1 second before re-evaluating screen buffer
    raise TimeoutError("UI failed to render in time.")

Integrating with n8n:
To integrate this local python engine with your broader marketing or CRM automation, wrap the Python script in a simple FastAPI server. You can then use an n8n HTTP Request node to trigger your local RPA agent securely, passing payloads back and forth between your desktop applications and your web-based CRMs.

5. Conclusion & Ready-to-use Workflow

Desktop automation doesn't require five-figure enterprise licenses. By combining open-source Computer Vision, LLM-based domain sanitization, and strict Python typing, you can build self-healing automation pipelines that survive UI changes.

You can absolutely take the code snippets above, integrate them with n8n, and build this pipeline yourself. However, if you want to skip the trial-and-error and get a production-ready system right now, I've packaged the complete engine.

VisionRPA: Type-Safe Desktop UI Automation & OCR Engine is available as a turnkey package with pre-built test fixtures, n8n JSON templates, and the complete Python source code.

Grab it here:

Instant Access on Whop: Link
Direct Download on Gumroad: Link (Use promo code EARLYBIRD for 20% off).

Stop letting hard-coded X/Y coordinates break your workflows. Build visually, execute locally.

🛠️ D'autres outils MR Studio qui pourraient vous intéresser :

n8n Cloud vs Self-Hosted: Real Cost for Small Teams

Tue, 13 Oct 2026 15:50:00 +0000

For most small teams without a reliable server owner, n8n Cloud is the cheaper operational choice even when self-hosting has the lower monthly invoice. Self-host Community Edition when someone already manages Linux, Docker, backups, monitoring, and recovery, or when data location and infrastructure control justify that work.

Partner disclosure. This guide includes a partner link to n8n Cloud. If you sign up through it, I may earn a commission at no extra cost to you.

Short answer: choose Cloud Starter when 2,500 monthly executions and one shared project are enough. Choose Cloud Pro when the team needs 10,000 executions, more concurrency, and more collaboration. Choose Community Edition only after naming the person who owns updates, security, backups, and restores.

The cost at a glance

Option	Published price	What the team still owns
n8n Cloud Starter	€20/month, billed annually	Workflows, credentials, access decisions, and process ownership
n8n Cloud Pro	€50/month, billed annually	The same business ownership, with more execution and collaboration capacity
Self-hosted Community Edition	No software license fee for permitted internal use	Server, database, TLS, updates, backups, monitoring, security, and recovery
Self-hosted Business	€667/month, billed annually	Infrastructure operations plus the paid license and its execution quota

These are the prices shown on the official n8n pricing page on July 18, 2026. Prices and plan limits can change. Starter includes 2,500 workflow executions, one shared project, and five concurrent executions. Pro includes 10,000 executions, three shared projects, and 20 concurrent executions. Both list unlimited users and workflows.

What n8n Cloud actually buys

The Cloud subscription is not just a place to run the editor. n8n hosts the service, so your team does not need to provision a VPS, expose it safely to the internet, maintain Docker, or schedule application updates. This removes an operational job from a small team.

Cloud also makes collaboration easier. Starter includes one shared project, while Pro includes three and adds admin roles, global variables, workflow history, and execution search. Those features matter when more than one person builds or supports workflows. Community Edition does not include Projects or workflow and credential sharing, so a technically free server can be a poor fit for a team that expects clean access boundaries.

There are still limits. Cloud pricing is based on complete workflow executions, and retained execution data is constrained by plan. The current pricing table lists maximum execution-log retention of seven days on Starter and 30 days on Pro. Cloud also fixes the hosting location for standard hosted plans. n8n currently says hosted data is stored on servers in Frankfurt, Germany.

What self-hosted Community Edition costs

The Community Edition includes almost the complete core feature set, but the official feature list excludes Projects, sharing, environments, SSO, external secrets, external binary storage, log streaming, multi-main mode, and Git version control. Registered Community Edition adds folders, debug-in-editor tools, and custom execution data, but it does not turn the instance into the Business plan.

The first invoice is usually the VPS. DigitalOcean currently lists a basic 1 GB Droplet at $6/month and 2 GB at $12/month. Its weekly backup option costs 20% of the Droplet price, while daily backups cost 30%. That produces a simple infrastructure range like this:

Example	Compute	Weekly provider backup	Annual infrastructure
1 GB light-use VPS	$6/month	$1.20/month	$86.40/year
2 GB small production starting point	$12/month	$2.40/month	$172.80/year

The 2 GB example is a planning starting point, not an n8n sizing guarantee. Workflow concurrency, Code nodes, large payloads, AI tasks, binary data, execution retention, and PostgreSQL all change the requirement. Hetzner and other providers may price similar servers differently by region. Provider prices exclude the value of your time and may exclude tax, IPv4, object storage, or other services.

The hidden self-hosted bill

Updates

n8n publishes minor releases frequently. Its self-hosted update guidance recommends updating at least monthly, reading release notes for breaking changes, and testing before production. Current Docker documentation lists stable version 2.26.8 as of this review. A safe update therefore needs a backup, a maintenance window, a smoke test, and a rollback path.

Backups and credentials

A workflow JSON export is useful, but it is not a complete instance backup. n8n stores workflows, credentials, and execution data in SQLite by default or in PostgreSQL when configured. The persistent .n8n directory also contains important data such as the encryption key. n8n uses that key to encrypt credentials before storing them in the database. The self-hosted n8n backup and restore guide turns those parts into a tested recovery sequence.

A practical recovery plan protects the database, the persistent n8n volume or explicit encryption key, the deployment configuration, and any binary-data location. It also proves that a restore works on a separate instance. A backup that has never been restored is only a hope.

Security and monitoring

Self-hosting means owning operating-system patches, Docker exposure, HTTPS, firewall rules, account access, database health, disk usage, and alerts. n8n's own Docker guide says self-hosting requires server, container, scaling, security, and application knowledge, and recommends Cloud for people without that experience because mistakes can cause data loss, security problems, and downtime.

This is not a reason to avoid self-hosting. It is a reason to price the operator. If maintenance and verification take one hour per month and that person's time is worth $30/hour, the labor assumption adds $360 per year. Two hours per month adds $720. Use your real internal rate rather than treating this time as free.

When self-hosting wins

You already operate servers. n8n becomes another monitored container instead of a new discipline.
You need control over data location. You choose the region, database, retention, network, and backup destination.
You need self-host-only capabilities. Bash execution and custom nodes can justify the infrastructure.
Your workload is high or unusual. You can size compute and storage around the workflow instead of a standard hosted plan.
You have a tested recovery owner. One named person can update, restore, and troubleshoot the instance.

My self-hosted n8n deployment case shows what that responsibility looks like in practice: Docker, PostgreSQL, Cloudflare, persistent storage, monitoring, and backups, not just one container command.

When n8n Cloud wins

No one owns infrastructure. The team needs workflows, not a second job maintaining the workflow server.
The first automation matters to revenue. A predictable platform bill is easier to defend than an unplanned recovery incident.
Several people need access. Shared projects and collaboration are part of the requirement, not optional extras.
The execution allowance fits. Starter or Pro covers the expected runs with room for retries, testing, and growth.
You want the fastest start. The team can build the workflow without first deploying a public production service.

If you are still deciding whether n8n fits the process at all, start with the plain-English n8n guide for small businesses. If the choice is between automation platforms, the Zapier vs Make vs n8n pricing comparison explains how each one counts usage.

If Cloud appears to fit, use the 14-day n8n Cloud trial guide to test three small workflows, break them deliberately, estimate production executions, and make a keep-or-cancel decision before paying.

Do not ignore the self-hosted license

Community Edition is source-available under n8n's Sustainable Use License, not a conventional open-source license. The official license FAQ allows internal business use, personal use, and consulting around n8n. It does not allow white-labeling n8n or hosting it and charging customers for access without a separate agreement.

License check: automating your own company's processes is the normal allowed case. If customers will access n8n, provide their own credentials, or buy a product whose value substantially derives from n8n, confirm the arrangement with n8n before building the business around Community Edition.

A five-minute decision rule

Estimate complete workflow executions for a normal month and a busy month.
List how many people need to build, inspect, or support workflows.
Decide whether Projects, sharing, SSO, environments, or version control are required.
Price the server, backups, storage, domain, and monitoring.
Add real operator time for updates, testing, incidents, and restores.
Name the recovery owner. If no one accepts the job, choose Cloud.

For a one-person technical operation, Community Edition can be excellent value. For a small team with no infrastructure owner, Cloud Starter is often cheaper than one avoidable incident. Cloud Pro becomes the practical choice when production volume and collaboration outgrow Starter. Self-hosted Business is a different buying decision for companies that need paid governance features while keeping the infrastructure under their control.

Sources checked

n8n partner link

Want to start without maintaining the server?

I may earn a commission if you sign up through this link, at no extra cost to you.

Try n8n Cloud

Still unsure which n8n setup fits?

Send the expected workflow volume, team size, data constraints, and who can own the server. I will help turn those inputs into a defensible hosting decision.

Compare the options

Originally published on FloxoLab.

How to Build a Complete Headless Micro-SaaS Backend in n8n (Auth, DataTables & AI Pipelines)

Mon, 12 Oct 2026 17:09:35 +0000

Every developer building a Micro-SaaS runs into the same wall: before you can monetize your core AI value proposition, you need to spend 40+ hours wiring up the exact same commodity infrastructure.

You write authentication middleware, implement password hashing, configure database migrations, stand up REST endpoints for basic CRUD, wire rate limiters, and connect AI queues. By the time you are ready to test product-market fit, you've burned two weeks writing code that does not differentiate your product in any way.

In this guide, we will break down how to bypass traditional backend infrastructure entirely by turning n8n into a full-scale, headless Micro-SaaS engine equipped with JWT authentication, internal data management, and an asynchronous AI generation pipeline.

1. The Bottleneck: The High Cost of Commodity Infrastructure

Traditional approaches to standing up a SaaS backend fall into two frustrating categories:

Full-stack frameworks (NestJS, FastAPI, Django): High setup overhead. You have to configure ORMs, setup migrations, implement JWT verification, write schema validations, and build custom workers to handle LLM rate limits and timeouts.
Managed BaaS (Firebase, Supabase): Excellent for basic relational data, but as soon as you need complex orchestration—such as chained LLM calls, background image synthesis, dynamic credit deduction, and webhook dispatching—you end up writing disparate edge functions that are difficult to debug and trace.

Using n8n as your core backend orchestrator provides a unified visual control plane. You get native state management, out-of-the-box secret handling, built-in DataTables for storage, and automated retries for flaky 3rd-party AI APIs—all accessible via clean REST endpoints for your frontend (React, Next.js, Svelte, or Vue).

2. The Architecture: Headless n8n SaaS Topology

The entire system operates on a headless decoupled model:

[ Frontend: Next.js / Tailwind ]
          │   (Bearer JWT)
          ▼
[ Gateway Webhook: POST /api/v1/* ]
          │
          ├───> [ Sub-Workflow: Verify-JWT ]
          │           ├── Valid  ──> Extracts `userId`, `tier`
          │           └── Invalid ─> Returns 401 Unauthorized
          │
          ├───> [ Router: Target Action ]
          │           ├── Action: /user/credits   ──> [ DataTables Read ]
          │           ├── Action: /items/crud     ──> [ CRUD DataTables ]
          │           └── Action: /ai/generate    ──> [ Async Queue ]
          │                                                 │
          │                                                 ▼
          │                                      [ AI Engine Pipeline ]
          │                                      - Prompt Sanitizer
          │                                      - Model Generation
          │                                      - S3 / Storage Dispatch
          ▼
[ Webhook Respond: JSON Payload ]

Core Structural Components:

API Gateway Webhook: A single entry point or modular route handlers receiving incoming HTTP requests from the client.
Authentication Sub-Workflow: An isolated execution pipeline executing cryptographic signature checks on incoming JWTs.
Native DataTables Storage: Acting as the operational transactional database for user state, credit balances, and entity storage.
AI Generation Pipeline: An isolated pipeline executing prompt validation, token budgeting, external model API execution (OpenAI, Stable Diffusion, Flux, or Anthropic), and database logging.

3. The Code & Logic

Let's implement the core building blocks required to make this production-ready.

Step 1: JWT Verification via n8n Code Node

When a request hits your Webhook node, the raw headers contain the Authorization: Bearer <token>. Instead of invoking external auth providers for every internal action, you can verify and decode the token directly within a native JavaScript Code node using native WebCrypto APIs.

// Code Node: Verify & Decode JWT
const authHeader = $input.item.json.headers['authorization'] || '';

if (!authHeader.startsWith('Bearer ')) {
  return [{
    json: {
      authorized: false,
      error: 'Missing or malformed Authorization header'
    }
  }];
}

const token = authHeader.split(' ')[1];
const secret = $env.JWT_SECRET; // Sourced from n8n Environment Variables

function base64UrlDecode(str) {
  let base64 = str.replace(/-/g, '+').replace(/_/g, '/');
  while (base64.length % 4) base64 += '=';
  return Buffer.from(base64, 'base64').toString('utf8');
}

try {
  const parts = token.split('.');
  if (parts.length !== 3) throw new Error('Invalid token structure');

  const [rawHeader, rawPayload, signature] = parts;
  const payload = JSON.parse(base64UrlDecode(rawPayload));

  // Check expiration (exp in seconds)
  const now = Math.floor(Date.now() / 1000);
  if (payload.exp && payload.exp < now) {
    return [{ json: { authorized: false, error: 'Token has expired' } }];
  }

  // Cryptographic signature check (HMAC-SHA256)
  const crypto = require('crypto');
  const expectedSig = crypto
    .createHmac('sha256', secret)
    .update(`${rawHeader}.${rawPayload}`)
    .digest('base64url');

  if (signature !== expectedSig) {
    return [{ json: { authorized: false, error: 'Signature mismatch' } }];
  }

  return [{
    json: {
      authorized: true,
      user: payload
    }
  }];
} catch (err) {
  return [{
    json: {
      authorized: false,
      error: err.message
    }
  }];
}

If authorized is false, your workflow branches to a Respond to Webhook node returning status 401 immediately, preventing unauthorized processing.

Step 2: Dynamic Input Sanitization & Credit Check

Before forwarding user prompts to AI models, we must prevent prompt injection, validate token bounds, and confirm the user has available credits in the DataTables layer.

// Code Node: Prompt Sanitize & Deduct Prep
const rawPrompt = $input.item.json.body.prompt || '';
const userCredits = $input.item.json.userData.credits || 0;
const COST_PER_GENERATION = 2;

// 1. Guard against empty/oversized prompts
const cleanPrompt = rawPrompt.trim().replace(/[<>\0]/g, '');

if (cleanPrompt.length < 5 || cleanPrompt.length > 1000) {
  throw new Error('Prompt length must be between 5 and 1000 characters.');
}

// 2. Validate balance
if (userCredits < COST_PER_GENERATION) {
  return [{
    json: {
      canExecute: false,
      error: 'Insufficient credit balance. Top-up required.',
      statusCode: 402
    }
  }];
}

return [{
  json: {
    canExecute: true,
    sanitizedPrompt: cleanPrompt,
    newCreditBalance: userCredits - COST_PER_GENERATION,
    timestamp: new Date().toISOString()
  }
}];

Step 3: Automated CRUD Mapping via DataTables

Instead of provisioning an external PostgreSQL or MongoDB instance during the prototyping phase, leverage n8n DataTables. By setting up dynamic table operations, a single webhook route /api/v1/records can handle all standard operations based on the HTTP method ($input.item.json.method):

GET: Returns records scoped to the extracted userId.
POST: Inserts a new row with automatic UUID generation.
PATCH: Updates metadata or status fields.
DELETE: Marks rows as deleted or removes them entirely.

This keeps your entire persistence layer contained directly within your workflow backups.

4. Deployment, Concurrency, and Error Handling

Running a Micro-SaaS backend in production requires strict reliability controls.

Handling AI Latency & Timeouts

AI image generators (Midjourney APIs, Flux, SDXL) frequently take 5 to 30 seconds to return. Running synchronous HTTP requests causes browser timeouts on client frontends.

The Solution: Webhook Handshake Pattern

Webhook receives the payload and issues a 202 Accepted response back to the client immediately with an execution_id.
The main workflow passes the payload to a sub-workflow via the Execute Sub-Workflow node configured asynchronously (Wait for Sub-Workflow Completion: false).
The worker sub-workflow runs the generation, uploads the resulting image asset to an S3-compatible bucket, and updates the DataTable record status from processing to completed.
The frontend polls a lightweight /api/v1/status?jobId=... endpoint or listens via SSE / WebSockets.

Preventing Rate Limits with Redis Queue Mode

If your n8n instance experiences sudden spikes in user traffic, running workflows in default execution mode can saturate server memory.

Run n8n in Queue Mode using Redis.
Deploy webhook workers independently from your execution workers.
Enforce rate-limiting headers using an upstream reverse proxy (like NGINX, Traefik, or Caddy) to throttle client IPs before they reach the n8n webhook listeners.

5. Conclusion & Ready-to-Use Boilerplate

You now have the architectural blueprint to eliminate traditional backend code and turn n8n into a modular, production-ready Micro-SaaS infrastructure. By centralizing authentication, state management, and AI execution inside n8n, you can deploy a functional product in an afternoon rather than weeks.

You can manually implement the workflows, tables, and scripts described above directly in your n8n editor.

Alternatively, if you want to skip the manual setup and get a fully configured, production-tested boilerplate with all webhook handlers, sub-workflows, token verification nodes, CRUD DataTables, and AI image pipelines pre-wired:

Instant Access on Whop: Get the Full-Stack Micro-SaaS Boilerplate
Direct Download on Gumroad: Download the Workflow Package — Use code EARLYBIRD at checkout for 20% off.

Both versions include the complete importable JSON architecture, API specifications, and test fixtures so you can launch your next SaaS backend immediately.

🛠️ D'autres outils MR Studio qui pourraient vous intéresser :

How to Back Up and Restore Self-Hosted n8n

Mon, 12 Oct 2026 15:50:00 +0000

A recoverable self-hosted n8n backup has four core parts: the database, the original encryption key, the deployment configuration and secrets, and any binary-data storage your executions still need. Back up the persistent .n8n volume even when PostgreSQL stores the main database. n8n documents that this directory can still contain the encryption key, logs, and source-control assets.

Partner disclosure. This guide includes a partner link to n8n Cloud. If you sign up through it, I may earn a commission at no extra cost to you.

Short answer: workflow JSON files alone are not enough. They do not recreate the complete instance state, and encrypted credentials are unusable without the key that encrypted them.

What must be in the backup

Asset	Why it matters	Typical location
Database	Workflows, encrypted credentials, users, projects, settings, and retained execution data	`~/.n8n/database.sqlite` or PostgreSQL
Encryption key	Decrypts the credentials stored in the database	`~/.n8n` settings or `N8N_ENCRYPTION_KEY`
Deployment config	Restores database connection, public URL, proxy, timezone, pruning, and execution behavior	Compose file, environment settings, secret references, proxy config
Binary data	Restores retained files handled by executions when filesystem or external storage is used	Persistent filesystem, database, or configured external store
Custom and community nodes	Allows restored workflows to load the same node types and versions	Package list, custom-node directory, container image, or build manifest

Do not put the raw encryption key, database password, OAuth secrets, or an unredacted environment file in a public repository. Keep a sanitized deployment definition in version control and protect the actual secrets in a restricted password manager, secret store, or encrypted backup.

Choose the database path before writing the runbook

Self-hosted n8n uses SQLite by default. The database file is ~/.n8n/database.sqlite. PostgreSQL is the other supported database option. The backup and restore commands must match the database your instance actually uses.

SQLite: capture a consistent persistent volume

The simplest small-instance method is a short maintenance window: stop the n8n application, archive its persistent volume, then start it again. Stopping writes avoids treating an arbitrary live file copy as a consistent database backup. For the standard Docker volume shown in n8n's installation guide, a generic sequence looks like this:

docker compose stop n8n
docker run --rm \
  -v n8n_data:/data:ro \
  -v "$PWD/backups:/backup" \
  alpine tar czf /backup/n8n-data-2026-07-18.tgz -C /data .
docker compose start n8n

Replace the service and volume names with the names in your deployment. If downtime is not acceptable, use a storage snapshot or SQLite-aware backup process that guarantees a consistent result. Do not assume that copying database.sqlite while executions are writing to it is safe.

PostgreSQL: use a database dump

PostgreSQL's official documentation recommends pg_dump for logical backups. A custom-format dump works with pg_restore and is practical for restoring into a fresh database. Adapt the connection values and run the tool from a host or database container that can reach PostgreSQL:

pg_dump --format=custom --file=n8n-2026-07-18.dump n8n

The dump does not replace the n8n persistent volume or explicit encryption key. It also does not capture the Compose file, environment settings, proxy configuration, or filesystem binary data. Store those as separate parts of the same dated backup set.

Add native n8n exports as a second recovery layer

n8n's Server CLI can export all database entity types. Its documentation positions this tooling for backups and migrations, including moves between SQLite and PostgreSQL. Execution-history data tables are excluded by default because they can be large, and can be included explicitly when your retention requirement needs them.

docker exec -u node n8n \
  n8n export:entities \
  --outputDir=/home/node/.n8n/cli-backup

Workflow and credential exports are also useful for selective recovery or versioned copies:

n8n export:workflow --backup --output=backups/workflows/
n8n export:credentials --backup --output=backups/credentials/

Avoid decrypted credential exports for routine backups. n8n supports a --decrypted flag for migrations to a different secret key, but the resulting files expose every sensitive value in plain text. If that exceptional path is necessary, isolate, encrypt, restrict, and delete the files after the migration.

A safe restore runbook

First restore into an isolated instance with no production webhooks, schedules, email sends, payment calls, or CRM writes. The first recovery test should never overwrite the only production copy.

Record the target. Use the same n8n version first, the same database type, and compatible custom-node versions. Upgrade only after the restored instance works.
Create fresh infrastructure. Prepare a new Docker volume or empty PostgreSQL database rather than clearing production.
Restore the original encryption key. Put the protected N8N_ENCRYPTION_KEY or original n8n settings in place before n8n reads the restored credentials.
Restore the database. Extract the stopped SQLite volume archive into the new volume, or restore the PostgreSQL dump into the new database.
Restore the surrounding state. Reapply deployment settings, binary storage, custom nodes, public URL settings, and reverse-proxy configuration.
Start without production traffic. Keep DNS, proxy routing, and outbound side effects isolated while checking startup and migration logs.
Verify the application. Confirm login, projects, workflows, credentials, node availability, execution history required by policy, and binary files that should still exist.
Run one safe test. Use test credentials or a non-destructive workflow and confirm that a credential can decrypt and authenticate.
Publish deliberately. Review which workflows should be published before switching traffic. Imported workflows can have different active-state behavior depending on the import path and deployment mode.

Restore a SQLite archive into a new volume

A new volume keeps the original recoverable while you inspect the restore. This example extracts the archive created above without deleting the production volume:

docker volume create n8n_restore_data
docker run --rm \
  -v n8n_restore_data:/data \
  -v "$PWD/backups:/backup:ro" \
  alpine tar xzf /backup/n8n-data-2026-07-18.tgz -C /data

Point a separate restore Compose file at n8n_restore_data. Do not bind it to the production hostname or webhook route until the checklist passes.

Restore PostgreSQL into a fresh database

createdb n8n_restore
pg_restore --dbname=n8n_restore n8n-2026-07-18.dump

Real deployments may need explicit host, user, role, ownership, TLS, and schema options. Test the exact command your operator will use and document it beside the backup job without embedding the password.

Restore-test checklist

The backup job has a timestamp, size, success state, and failure alert.
The database and encryption key come from the same recoverable setup.
The restore starts on a separate hostname, volume, and database.
Credential nodes open without decryption errors and one test authentication succeeds.
Required custom or community nodes load at the expected versions.
Published workflows, schedules, and webhook paths are reviewed before traffic moves.
Required retained binary files can be opened.
The restore time and missing manual steps are recorded for the next test.

Common backup failures

Mistake	What breaks during recovery
Only exporting workflow JSON	Users, projects, settings, retained executions, and complete credential state are not restored as one instance
Database without the original key	Credentials remain encrypted but cannot be used
Copying a live SQLite file casually	The backup may not represent one consistent database state
Skipping binary storage	Execution records may exist while retained documents or images are missing
Restoring straight over production	A bad archive or wrong configuration can remove the working recovery path
Never testing the restore	Missing keys, permissions, node packages, and undocumented steps appear during the incident

Common questions

Where does Docker store self-hosted n8n data?

n8n's standard Docker example mounts a named n8n_data volume at /home/node/.n8n. Your Compose file may use a different volume or bind mount, so inspect the deployment rather than assuming the example name.

Does exporting workflows back up credentials?

Not by itself. n8n provides separate workflow and credential export commands, plus the broader export:entities command. For same-instance disaster recovery, the database, original encryption key, config, and storage remain the stronger complete backup set.

Can I restore into a newer n8n version?

Restore the recorded version first when possible. This separates backup problems from application migrations. After the restored instance passes its checks, read the intervening release notes, take another backup, and perform the upgrade as a separate controlled change.

Sources checked

n8n partner link

Prefer a managed recovery path?

I may earn a commission if you sign up through this link, at no extra cost to you.

Try n8n Cloud

Need the recovery path documented?

Send the database type, deployment shape, storage locations, and recovery target. I will help map a backup set and an isolated restore test without exposing production secrets.

Map the restore

Originally published on FloxoLab.

How to Control Any Legacy Desktop App from n8n with a Type-Safe Python Vision Endpoint

Mon, 12 Oct 2026 10:56:13 +0000

How to Control Any Legacy Desktop App from n8n with a Type-Safe Python Vision Endpoint

Legacy desktop applications—custom ERPs, Delphi clients, SAP GUI, Citrix windows, and air-gapped financial systems—remain the bane of modern workflow orchestration. They lack REST endpoints, expose zero webhook triggers, and fail to expose accessibility tree nodes for conventional UI automation.

Traditionally, dev teams face two flawed paths:

Enterprise RPA suites (UiPath, Automation Anywhere, Microsoft Power Automate Desktop): Costs scale into five figures annually, require dedicated Windows Server instances, and depend on proprietary orchestrators disconnected from modern CI/CD or n8n topologies.
Brittle native scripts: Unsynchronized pyautogui scripts running on infinite loops with static time.sleep() calls, collapsing at the first shifted pixel or dynamic modal dialogue.

This guide demonstrates an alternative: a local, type-safe Python FastAPI daemon that acts as an OS-level microservice, controllable directly via standard n8n workflows using screen capture, coordinate-aware OCR, and deterministic vision targeting.

1. The Bottleneck: The Fragility of Native Selectors

Commercial RPA platforms rely heavily on accessibility frameworks (Microsoft UI Automation, MSAA, IAccessible2). However, legacy Win32, Java Swing, Qt, and WPF apps often emit unpopulated element trees:

[Desktop]
  └─ [Window: LegacyBilling.exe]
       └─ [Pane: CustomCanvas] <-- Zero child nodes; totally opaque to DOM/UI inspection

When accessibility selectors fail, commercial tools fall back to basic coordinate clicks or image-template matching (cv2.matchTemplate), which fails under minor antialiasing shifts, dynamic theme updates, or resolution changes.

The Direct Vision-to-Action Protocol

By treating the desktop screen as an ephemeral API, we establish a stateless loop:

Inspect: Frame-buffer capture via native C-level screen grabbers (mss).
Extract & Locate: Type-safe OCR parsing with coordinate bounding boxes normalized to DPI.
Assert: Pydantic schema validation ensuring required text or anchors exist before execution.
Dispatch: Hardware-level cursor/keyboard dispatch.
Acknowledge: HTTP 200 payload returned to n8n with extracted data or execution state.

2. The Architecture

The automation stack decouples orchestration from execution:

┌─────────────────┐       HTTP / JSON        ┌──────────────────────────────┐
│   n8n Server    │  ────────────────────>   │   FastAPI Local Agent (OS)   │
│ (Cloud/Self-Host│  <────────────────────   │   (Listening on 127.0.0.1)   │
└─────────────────┘      Structured Data     └──────────────┬───────────────┘
                                                            │
                                    ┌───────────────────────┴───────────────────────┐
                                    ▼                                               ▼
                         ┌─────────────────────┐                         ┌─────────────────────┐
                         │  OCR / Vision Core  │                         │ PyAutoGUI / ctypes  │
                         │ (EasyOCR/Tesseract) │                         │ (Input Dispatch)    │
                         └─────────────────────┘                         └─────────────────────┘

n8n Orchestrator: Handles scheduling, error retries, CRM integrations (PostgreSQL, HubSpot, Slack), and flow logic.
FastAPI Daemon: Runs directly on the target host (Windows/macOS/Linux), exposing type-safe endpoints secured with an internal Bearer token.
Vision Engine: Runs localized OCR with bounding boxes returned as normalized (x_min, y_min, x_max, y_max) values.

3. The Code & Logic

3.1 The FastAPI Agent

Below is the complete implementation of the core endpoint daemon handling coordinate targeting and OCR extraction.

# endpoint.py
import os
from typing import Optional, List
import mss
import numpy as np
import cv2
import pytesseract
import pyautogui
from fastapi import FastAPI, HTTPException, Security, status
from fastapi.security import HTTPBearer, HTTPAuthorizationCredentials
from pydantic import BaseModel, Field

pyautogui.FAILSAFE = True  # Slam cursor to corner to abort

app = FastAPI(title="Desktop Vision Endpoint", version="1.0.0")
security = HTTPBearer()
AUTH_TOKEN = os.getenv("AGENT_AUTH_TOKEN", "dev_secret_token_change_me")

def verify_token(credentials: HTTPAuthorizationCredentials = Security(security)):
    if credentials.credentials != AUTH_TOKEN:
        raise HTTPException(
            status_code=status.HTTP_401_UNAUTHORIZED,
            detail="Invalid automation bearer token"
        )
    return credentials.credentials

class Coordinate(BaseModel):
    x: int
    y: int

class OCRMatch(BaseModel):
    text: str
    confidence: float
    center: Coordinate
    bounding_box: List[int] = Field(..., description="[x, y, w, h]")

class ClickRequest(BaseModel):
    target_text: Optional[str] = None
    fallback_coords: Optional[Coordinate] = None
    double_click: bool = False
    offset_x: int = 0
    offset_y: int = 0

class TypeRequest(BaseModel):
    text: str
    clear_field_first: bool = True
    submit_enter: bool = False

def capture_screen_matrix() -> np.ndarray:
    with mss.mss() as sct:
        monitor = sct.monitors[1]  # Primary monitor
        screenshot = np.array(sct.grab(monitor))
        # Convert BGRA to RGB
        return cv2.cvtColor(screenshot, cv2.COLOR_BGRA2RGB)

@app.post("/ocr/scan", response_model=List[OCRMatch], dependencies=[Security(verify_token)])
def scan_screen(contains: Optional[str] = None):
    image = capture_screen_matrix()
    data = pytesseract.image_to_data(image, output_type=pytesseract.Output.DICT)
    
    matches: List[OCRMatch] = []
    n_boxes = len(data["text"])
    
    for i in range(n_boxes):
        text = data["text"][i].strip()
        conf = float(data["conf"][i])
        
        if conf > 40.0 and len(text) > 0:
            if contains and contains.lower() not in text.lower():
                continue
                
            x, y, w, h = data["left"][i], data["top"][i], data["width"][i], data["height"][i]
            matches.append(OCRMatch(
                text=text,
                confidence=conf,
                center=Coordinate(x=x + w // 2, y=y + h // 2),
                bounding_box=[x, y, w, h]
            ))
            
    return matches

@app.post("/action/click", dependencies=[Security(verify_token)])
def click_element(req: ClickRequest):
    target_x, target_y = None, None
    
    if req.target_text:
        matches = scan_screen(contains=req.target_text)
        if matches:
            # Pick the highest confidence match
            best = max(matches, key=lambda m: m.confidence)
            target_x = best.center.x + req.offset_x
            target_y = best.center.y + req.offset_y
            
    if target_x is None and req.fallback_coords:
        target_x = req.fallback_coords.x + req.offset_x
        target_y = req.fallback_coords.y + req.offset_y
        
    if target_x is None:
        raise HTTPException(status_code=404, detail="Target not located on display")
        
    pyautogui.moveTo(target_x, target_y, duration=0.2)
    if req.double_click:
        pyautogui.doubleClick()
    else:
        pyautogui.click()
        
    return {"status": "success", "clicked_at": {"x": target_x, "y": target_y}}

@app.post("/action/type", dependencies=[Security(verify_token)])
def write_text(req: TypeRequest):
    if req.clear_field_first:
        pyautogui.hotkey("ctrl", "a")
        pyautogui.press("backspace")
        
    pyautogui.write(req.text, interval=0.03)
    
    if req.submit_enter:
        pyautogui.press("enter")
        
    return {"status": "success", "typed_chars": len(req.text)}

if __name__ == "__main__":
    import uvicorn
    uvicorn.run(app, host="127.0.0.1", port=8765)

3.2 The n8n Integration Loop

In n8n, interact with the local agent using standard HTTP Request nodes over local loopback (or via a secure Tailscale mesh if n8n is hosted remotely).

Here is a raw n8n HTTP Request node configuration targeting the /action/click endpoint:

{
  "parameters": {
    "method": "POST",
    "url": "http://127.0.0.1:8765/action/click",
    "authentication": "genericCredentialType",
    "genericAuthType": "httpHeaderAuth",
    "sendHeaders": true,
    "headerParameters": {
      "parameters": [
        {
          "name": "Authorization",
          "value": "Bearer dev_secret_token_change_me"
        }
      ]
    },
    "sendBody": true,
    "contentType": "raw",
    "rawContentType": "application/json",
    "body": "={\n  \"target_text\": \"Submit Order\",\n  \"offset_x\": 0,\n  \"offset_y\": 0,\n  \"double_click\": false\n}",
    "options": {
      "timeout": 5000
    }
  },
  "name": "Click 'Submit Order'",
  "type": "n8n-nodes-base.httpRequest",
  "typeVersion": 4.2,
  "position": [460, 240]
}

4. Deployment, DPI Scaling & Performance

When orchestrating OS interactions from a server pipeline, three production factors determine stability:

1. High-DPI Display Scaling

On Windows systems with 125% or 150% UI scale (common on laptops and 4K workstations), OpenCV and PyAutoGUI coordinates may drift if your Python process is not marked DPI-aware. Fix this at initialization in your runner:

import sys
if sys.platform == "win32":
    import ctypes
    ctypes.windll.shcore.SetProcessDpiAwareness(2) # Per-monitor DPI aware

2. Tailscale & Remote n8n Instances

If your n8n orchestrator is cloud-hosted while your target client runs on a private Windows VM behind NAT:

Do not expose the FastAPI port to the public internet.
Install Tailscale on the Windows agent and n8n container.
Direct n8n to communicate with the host's 100.x.y.z Tailscale mesh IP with token validation.

3. Deterministic Retries in n8n

Desktop GUIs exhibit variable latency. Avoid using raw delays (Wait nodes). Instead, implement a Polling Retry Loop in n8n using an If condition:

Execute /ocr/scan?contains=Invoice.
Check if the returned array length is > 0.
If 0, wait 500ms and increment a retry counter.
Route to /action/click only when the element is detected on screen.

5. Conclusion & Ready-to-Use Package

By converting raw OS displays into type-safe, HTTP-accessible endpoints, you eliminate proprietary RPA overhead and maintain all business logic within unified n8n workflows.

You can manually implement the boilerplate above, configure PyTesseract, tune the bounding-box logic, and map out the n8n HTTP schemas yourself.

Alternatively, you can grab the turnkey production-ready package—which includes pre-configured FastAPI binaries, packaged system-tray runners, auto-healing OCR wrappers, and importable n8n workflow templates:

Instant Access on Whop
Direct Download on Gumroad — Use coupon code EARLYBIRD at checkout for 20% off.

🛠️ D'autres outils MR Studio qui pourraient vous intéresser :

How to Deduplicate Leads in n8n Before They Reach Your CRM

Sun, 11 Oct 2026 15:50:00 +0000

Lead deduplication is not one filter. A reliable n8n workflow separates repeated submissions from repeated people, normalizes the values used for comparison, checks persistent records, and lets the CRM enforce uniqueness whenever the destination supports it.

Partner disclosure. This guide includes a partner link to n8n Cloud. If you sign up through it, I may earn a commission at no extra cost to you.

Short answer: use a stable source ID to stop the same event twice, normalized email or phone to find an existing person, and a CRM-native create/update or upsert operation for the final write. Never auto-merge two records on name alone.

First identify which duplicate you are stopping

Duplicate type	Example	Best first control
Repeated item in one execution	A spreadsheet import contains the same row twice	Remove Duplicates on the current input
Repeated source event	A webhook or retry delivers submission `lead_8472` again	Persistent check on the stable source ID
Same person from another source	The same customer submits a website form after a Facebook form	Normalized identity lookup in the CRM
Conflicting identity	Email matches one contact while phone matches another	Human review, not an automatic merge

The Facebook Lead Ads workflow uses a Meta lead ID to stop one submission from creating several sheet rows. This guide goes further by handling several sources and an existing CRM full of contacts.

Choose identity keys before building nodes

Key	What it proves	Rule
Source record or submission ID	The same source event or object	Strongest key for replay protection, but not for matching a person across systems
Normalized email	Usually the same inbox	Good exact contact key when present and valid
Normalized phone	Usually the same reachable number	Useful with country context; shared business or family numbers need caution
Name	Only that the text looks similar	Use as review context, never as the only automatic merge key

Decide field ownership too. A new form may fill a missing phone number, but it should not silently replace a verified CRM email, owner, lifecycle stage, or consent value. Deduplication decides which record to use. A separate update policy decides which fields may change.

A practical n8n workflow shape

Lead trigger
  → Edit Fields: normalize keys
  → Remove Duplicates: current batch or repeated event
  → Data Table or CRM: persistent lookup
  → Switch: new / exact match / conflict
  → CRM: create or update
  → Data Table: record source key and CRM ID
  → Alert only when review or failure is needed

Start with one lead source and one CRM. The same pattern can later sit behind Facebook forms, website forms, imports, chat, and email without giving each source a different duplicate policy.

Step 1: normalize the fields once

Add an Edit Fields node immediately after the trigger. Preserve the original values for audit and display, then create separate comparison fields:

source_key
email_original
email_key
phone_original
phone_key
full_name
source
received_at

For an email comparison key, an n8n expression can trim whitespace and use lowercase:

{{ ($json.email || '').trim().toLowerCase() }}

Build source_key from the provider and its stable ID, for example facebook:lead_8472 or website:submission_193. Do not concatenate name and timestamp and call that stable. For phone numbers, remove presentation punctuation and normalize with the correct country context. Simply stripping every non-digit character can make two different international numbers look deceptively similar.

Step 2: use Remove Duplicates for the narrow job it does well

For duplicate rows arriving together, configure Remove Duplicates → Remove Items Repeated Within Current Input, choose Selected Fields, and compare source_key. This is ideal for imports and batched records.

For the same source event arriving in later executions, the node also supports Remove Items Processed in Previous Executions. Use Value Is New and deduplicate on source_key. Scope can be the individual node or the workflow. Current n8n documentation says the default history size is 10,000 items.

Do not treat that history as your customer database. The history has a configured size, can be cleared, and only knows the values you gave that node or workflow. It cannot decide that two different source IDs belong to the same person.

Step 3: add a persistent lookup

Option A: n8n Data Table for a small lead ledger

A Data Table is a practical first version for a small business that does not yet have strong CRM lookup rules. Create a table such as lead_identity with these columns:

source_key
email_key
phone_key
crm_id
status
first_seen_at
last_seen_at

The current Data Table node can check whether a row exists, get rows, insert, update, and upsert using conditions. Search the strongest available key before the CRM write, then upsert the final crm_id only after the CRM succeeds.

n8n describes Data Tables as light to moderate storage. The default total limit across all tables in an instance is 50 MB, although self-hosted instances can change it. That makes a table useful as a compact identity ledger, not a replacement for a mature CRM or warehouse.

Option B: search the CRM directly

If the CRM already owns the customer record, query it first. The current n8n HubSpot node, for example, supports searching contacts and a Create/Update a contact operation. Other CRM nodes expose different operations, so check the destination's exact contract before copying a pattern.

Prefer a CRM record ID or custom unique source ID once you have one. HubSpot's current Contacts API can retrieve by email and batch upsert by email or a custom unique identifier. It also notes that partial upserts are not supported when email is the identifier, which is one reason not to send an incomplete payload blindly.

Step 4: route new, matched, and conflicting leads

Use a Switch node with three explicit outcomes:

No match: create the contact, then save the returned CRM ID with the source key.
One safe match: update only allowed fields and attach the new source or submission as an activity.
Conflict: do not create or merge automatically. Send the candidate record IDs and incoming values to an owner for review.

A conflict includes more than two search results. It also includes email matching contact A while phone matches contact B, or a source ID pointing to a record whose verified identity now disagrees with the payload. Preserve the lead and notify someone. Silent deletion is not deduplication.

Step 5: make the CRM write duplicate-safe

Use the destination's create/update or upsert operation when it can enforce a unique identifier. This is stronger than a separate search followed by create because two n8n executions can run at nearly the same time, both see no result, and both create a contact before either writes the ledger.

If the CRM cannot upsert atomically, use its unique-field constraint, serialize the critical section, or put the identity key in a database with a unique index. Catch the destination's duplicate response and retrieve the existing record instead of treating every conflict as an unrecoverable failure.

After a successful write, upsert the source key and returned CRM ID into the Data Table. Then send notifications or start follow-up. This ordering prevents the team from receiving a success alert for a contact that never reached the CRM.

Test with a small duplicate matrix

Test	Expected result
Same source ID delivered twice	One CRM record; the replay is stopped or attached without another create
Different source ID, same normalized email	Existing contact updated according to field rules
Same phone with different formatting	One candidate after country-aware normalization
Same name, different email and phone	New record or manual review, never an automatic merge by name
Email matches A, phone matches B	Conflict branch with both record IDs visible
Two identical executions started together	One destination record because the final write enforces uniqueness
CRM write fails	No success alert and no ledger row marked complete

Common mistakes

Comparing raw email or phone values without normalization.
Using name as a unique key.
Assuming a source submission ID identifies the same person across every channel.
Dropping duplicates without recording the new campaign, form, message, or timestamp.
Overwriting verified CRM fields with blank or lower-confidence form values.
Running search and create concurrently without a destination uniqueness control.
Using a temporary in-workflow list as the only long-term duplicate barrier.

Useful questions before publishing

Can Remove Duplicates replace a CRM lookup?

No. It is useful for repeated items and remembered values, but it does not understand an existing customer record, alternate email, shared phone, merge history, or field ownership.

Should email or phone be the main key?

Use the strongest verified identifier your process reliably collects. Email is often the simplest contact key. Phone can be useful after country-aware normalization. Keep a stable source ID for replay protection even when email is the CRM match key.

Should a duplicate lead be discarded?

Usually not. The person may have submitted a new service request or responded to a different campaign. Reuse the contact record, then preserve the new submission as an activity, note, deal, or source event.

Privacy and operating rules

Store only the identity fields needed for matching and follow-up.
Restrict Data Tables, execution data, and CRM credentials to the responsible project members.
Set retention rules for rejected and ambiguous records.
Do not place full lead payloads in chat alerts when a secure CRM link is enough.
Document who resolves conflicts and how quickly the review queue should be checked.

For retries around state-changing API calls, use the separate duplicate-safe n8n API retry pattern. That guide protects one operation from being repeated. This guide protects CRM identity across leads and sources.

Sources checked

n8n Cloud for small teams

Test the duplicate guard without maintaining a server

n8n Cloud is the simplest place to build this workflow if you want to focus on the lead logic instead of hosting. Affiliate disclosure: I may earn a commission if you sign up through this link, at no extra cost to you.

Try n8n Cloud

Need the CRM identity rules mapped?

Send the lead sources, available IDs, CRM, match fields, and examples of known duplicates. I will help define the new, matched, and review paths before the workflow writes production records.

Map the duplicate guard

Originally published on FloxoLab.

Facebook Lead Ads to Google Sheets and Email Without Zapier

Sat, 10 Oct 2026 15:50:00 +0000

The practical no-Zapier path is a four-node n8n workflow: Facebook Lead Ads Trigger → Edit Fields → Google Sheets → Gmail. A new instant-form submission starts the workflow. n8n normalizes the fields, appends or updates one row using the Meta lead ID, then sends an internal email alert with a link to the sheet.

Partner disclosure. This guide includes a partner link to n8n Cloud. If you sign up through it, I may earn a commission at no extra cost to you.

Short answer: this workflow replaces manual CSV downloads and copy-paste. It does not replace Ads Manager, consent language, lead ownership rules, or a proper CRM when several people need assignment, audit history, and pipeline reporting.

Check Meta's direct Google Sheets option first

Some Meta Business Suite accounts now show a direct Google Sheets connection under All tools → Instant forms → CRM setup → Google Sheets. If it appears in your account and your only requirement is to place each new form submission in one spreadsheet, try that route first. It is simpler than creating a Meta developer app and does not require a separate automation-platform subscription.

What the business needs	Best starting point
Send one instant form to one Google Sheet	Meta's direct Google Sheets connection, when available
Rename fields, filter leads, prevent duplicate rows, and send an email	n8n
Update several tools, route leads by answers, or add approval and error handling	n8n, or n8n connected to a CRM
Assign owners, track a sales pipeline, and keep a complete activity history	A proper CRM, with n8n handling the surrounding automation when needed

Meta rolls out and changes Business Suite features by account and region, so the Google Sheets choice may not be visible everywhere. This guide covers the n8n route because the workflow does more than copy a lead: it normalizes the data, uses the lead ID for safer writes, and sends an internal notification. The four required steps use built-in n8n nodes, so the basic workflow does not need a custom HTTP Request node.

What this workflow should do

Stage	Node	Output
Capture	Facebook Lead Ads Trigger	The lead ID, form and ad context, submission time, and submitted fields
Normalize	Edit Fields	Stable names such as `lead_id`, `full_name`, `email`, and `phone`
Store	Google Sheets	One row per lead, keyed by `lead_id`
Notify	Gmail or Send Email	An internal alert with the useful lead fields and a sheet link

Keep the email internal at first. An automatic message to the prospect is a separate business decision because the form must clearly support that use, the address must be valid, and local privacy and marketing-consent rules still apply.

Prerequisites for the n8n route

A Meta Page, an active instant form, and access to the relevant ad account and Page.
A Meta for Developers account and an app with Facebook Login or Facebook Login for Business.
A public HTTPS n8n URL. Meta cannot deliver production webhook events to a private localhost address.
A Google account or service account that can edit the destination spreadsheet.
A Gmail credential, SMTP credential, or another email provider supported by your n8n instance.

n8n's current Facebook Lead Ads credential uses OAuth2. You copy the OAuth Redirect URL from n8n into the Meta app, then add the Meta App ID and App Secret to the n8n credential. For production, n8n's official setup also calls for a Privacy Policy URL, Live app mode, advanced access for the requested feature, and business verification where Meta requires it.

Meta permissions and leads access

Meta's current lead-retrieval documentation separates access by the data you request. For complete lead and ad-level data it lists leads_retrieval, pages_show_list, pages_read_engagement, pages_manage_ads, and ads_management. Webhook setup also uses pages_manage_metadata. The token must come from someone with the required Page and advertising access.

Leads Access Manager can narrow who or which integration can retrieve leads. A person being able to view the Page does not automatically prove that the app can fetch every lead. When the trigger connects but no real data arrives, check business asset access and lead access before rebuilding the workflow.

Build the workflow in n8n

1. Configure Facebook Lead Ads Trigger

Add Facebook Lead Ads Trigger and create its OAuth2 credential.
In Meta for Developers, add the n8n OAuth Redirect URL to the allowed redirect URIs.
Enter the Meta App ID and App Secret in n8n, then complete the Facebook authorization.
Select the Page and form that should start this workflow.
Run a test with Meta's Lead Ads Testing Tool and inspect the actual output before mapping fields.

Do not test against a live production app casually. n8n documents that Facebook Lead Ads allows one webhook per app. Switching between test and production overwrites the registered webhook URL. If a live workflow must be tested, plan a short controlled window, unpublish it, test, then publish it again and verify a fresh production lead.

2. Normalize the lead fields

Add an Edit Fields node after the trigger. Use the test execution to map the fields actually returned by your form. Meta forms can use custom question names, and their answers may arrive inside a field-data collection rather than as the exact column names you want.

Use a small stable record:

lead_id
created_time
full_name
email
phone
form_id
ad_id
campaign_id
source
status
owner

Store the Meta lead ID even if nobody sees it day to day. It gives the next node a durable key for a basic duplicate check and makes support investigations much easier than matching by name or email alone.

3. Write to Google Sheets without duplicate rows

Create the header row in Google Sheets first, then add the Google Sheets node. Choose Sheet Within Document → Append or Update Row, select the spreadsheet and tab, and match on lead_id. n8n also offers Append Row, but the append-or-update operation is safer when a delivery or execution is retried.

Map each normalized field to one column. Keep computed formulas and team notes in separate columns so a later field-map change does not overwrite them. A lightweight sheet can start with status = New and a blank owner, but it should not pretend to be a full CRM forever.

If several forms or channels feed the same CRM, a source lead ID is not enough to recognize the same person across systems. Use the broader n8n lead deduplication pattern to normalize identity keys, route conflicts, and update the right contact.

4. Send the internal email after the row succeeds

Put the Gmail or Send Email node after Google Sheets. This order matters: the team should not receive a success alert for a lead that failed to save. A concise internal message can include the name, email, phone, form source, submission time, and a link to the shared sheet.

Subject: New Facebook lead: {{ full_name }}

Name: {{ full_name }}
Email: {{ email }}
Phone: {{ phone }}
Form: {{ form_id }}
Lead ID: {{ lead_id }}

Open lead sheet: https://docs.google.com/spreadsheets/d/...

The placeholders above describe the message shape. Insert them through n8n's expression picker from your normalized node instead of pasting names that do not exist in your execution.

Test the path before publishing

Create one test lead with a recognizable test name and a safe email address.
Confirm the trigger execution contains the expected Page, form, lead ID, and question values.
Confirm one row appears under the correct headers.
Run the same normalized item again and confirm it updates the existing lead_id row instead of adding another row.
Confirm the internal email arrives only after the sheet operation succeeds.
Publish the workflow and create a separate production test lead.
Record who owns Meta access, Google access, and the alert mailbox so the integration is maintainable.

Common failures and the fastest checks

Symptom	Check first
The trigger connects but receives no real leads	Live app mode, Page selection, form selection, Leads Access Manager, and required Meta permissions
Testing works, production does not	Whether the test webhook replaced the production webhook, then republish and retest
Production works, testing does not	The same single-webhook limitation and whether the workflow is still published
Names or answers land in the wrong columns	The real test payload, custom form question names, and Edit Fields mapping
One lead creates several rows	Use Append or Update Row with `lead_id`, then inspect execution retries
The sheet saves but no email arrives	Email credential, sender permissions, recipient address, provider quota, and spam folder
Meta OAuth suddenly fails	App status, business verification, changed permissions, removed business integration, or expired access

Privacy and operating rules

Collect only the fields the sales or service process genuinely needs.
Restrict the spreadsheet to the people responsible for follow-up.
Do not put App Secrets, access tokens, or OAuth credentials in the sheet or email body.
Set a retention rule for old leads and document who can delete or export them.
Use a shared business mailbox or documented owner, not an employee's unexplained personal account.
Add a failure alert or error workflow so a broken credential does not silently stop lead capture.

If your intake already starts with Google Forms rather than Meta instant forms, the simpler Google Forms, Sheets, and Gmail workflow may be enough. This guide is specifically for retrieving leads submitted inside Facebook or Instagram lead ads and routing them through n8n.

Sources checked

n8n Cloud for small teams

Try the workflow without maintaining a server

n8n Cloud is the simplest place to build and test this workflow if you do not want to manage hosting. I may earn a commission if you sign up through this link, at no extra cost to you.

Try n8n Cloud

Need the lead path mapped?

Send the form fields, Page and account setup, spreadsheet columns, notification owner, and expected response time. I will help scope a workflow with clear access, duplicate, and failure handling.

Map the workflow

Originally published on FloxoLab.

Architecting a Zero-Loss Webhook Ingestion Engine with n8n and Redis (5k req/s DLQ)

Tue, 06 Oct 2026 08:26:44 +0000

Architecting a Zero-Loss Webhook Ingestion Engine with n8n and Redis (5k req/s DLQ)

Webhooks are inherently fragile. If an upstream payment gateway emits an invoice event during a scheduled database restart, or if your downstream CRM hits an unannounced rate limit (HTTP 429), standard automation flows drop the execution.

By default, native webhook nodes in low-code orchestration engines (like standard n8n workflows, Zapier, or Make) execute synchronously. If downstream services timeout or throw an uncaught 5xx error, the payload vanishes into log oblivion.

In this technical guide, we will design and deploy a Self-Healing Webhook Dead-Letter Queue (DLQ) & Payload Recovery Engine using n8n and Redis. This architecture isolates the ingestion layer from downstream consumers, enforces exponential backoff with full jitter, preserves metadata, and guarantees exactly-once processing using SHA-256 idempotency checks.

1. The Bottleneck: The Flaws of Synchronous Webhook Ingestion

Most teams route incoming webhooks directly to their target business logic:

[External Provider] ---> [Sync HTTP Endpoint (n8n)] ---> [Process / Parse] ---> [Update Postgres / HubSpot]

This simple pattern breaks catastrophically in production due to three distinct failure modes:

Unbuffered Burst Traffic: Black Friday or marketing flash sales can turn a typical 10 req/s stream into 3,000 req/s. Synchronous engines run out of Node.js event loop capacity or database connection pools, dropping connections with ECONNRESET.
The Cascading 429 Problem: When an external CRM starts returning 429 Too Many Requests, naive execution loops retry immediately or sequentially, worsening the rate limit and burning through workflow execution quotas.
Payload Loss on Uncaught Exceptions: If schema validation fails midway or an unhandled null parameter crashes an execution node, standard error handlers rarely isolate the raw payload for stateful replays without human intervention.

Commercial managed queues (like AWS SQS FIFO or Google Cloud Pub/Sub paired with Lambda) solve this, but they introduce vendor lock-in, complex IAM setup, and high maintenance costs when all you need is a deterministic, observable queue integrated into your n8n workflow ecosystem.

2. The Architecture: Decoupled Buffering & Replay Engine

To achieve true zero-loss architecture, we decouple ingestion from processing using Redis streams and sorted sets (ZSET).

                           +---------------------------------------+
                           |          Ingestion Layer              |
[Webhook Provider] ------> |  n8n Webhook Node (202 Accepted)      |
                           |  Compute SHA-256 Idempotency Key      |
                           |  Push to Redis Stream (Ingestion Bus) |
                           +---------------------------------------+
                                              |
                                              v
                           +---------------------------------------+
                           |          Worker / Consumer            |
                           |  Read from Stream (XREADGROUP)        |
                           |  Attempt Processing & Routing         |
                           +---------------------------------------+
                                      /               \
                            [Success]/                 \[Failure / 429 / 5xx]
                                    v                   v
                           +----------------+   +---------------------------------------+
                           |  Acknowledge   |   |        Retry Pipeline (ZSET)          |
                           |  (XACK)        |   |  Retry Count < Max?                   |
                           +----------------+   |  Calculate Exponential Backoff+Jitter |
                                                +---------------------------------------+
                                                        |                      |
                                                 [Under Limit]            [Max Retries]
                                                        |                      |
                                                        v                      v
                                                +----------------+   +-------------------+
                                                | Re-enqueue to  |   | Isolated DLQ      |
                                                | Stream at T+d  |   | Payload Sanitized |
                                                +----------------+   | Metadata Attached |
                                                                     +-------------------+
                                                                               |
                                                                               v
                                                                     +-------------------+
                                                                     | Auto/Manual Replay|
                                                                     | (Idempotent Sync) |
                                                                     +-------------------+

Pipeline Stages

Ingestion & De-duplication: The webhook accepts the payload, generates a SHA-256 hash of the deterministic payload body, and issues a Redis SETNX lock to prevent duplicate deliveries. The caller immediately receives 202 Accepted.
Buffer Stream: Payloads enter a Redis Stream (webhook:stream:raw).
Consumer & Error Catching: n8n worker loops consume batches. If an upstream call fails with a retryable code (408, 429, 500, 502, 503, 504), it moves to a scheduled retry set.
Exponential Backoff with Full Jitter: Instead of retrying on static intervals, the pipeline computes:
\[\text{Delay} = \min(\text{MaxDelay}, \text{Base} \times 2^{\text{attempt}}) \times \text{random}(0.5, 1.5)\]
Isolated DLQ: After $N$ failed retries (e.g., 5 attempts), the payload is sent to webhook:dlq:dead, sanitizing sensitive headers (e.g., Authorization) while preserving headers, execution error stacks, and original timestamps.

3. The Code & Logic

Below are the core n8n JavaScript Code node snippets that drive this engine.

A. Deterministic Idempotency Key & Header Sanitization

Add this to an n8n Code Node right after the incoming Webhook Node:

const crypto = require('crypto');

// 1. Extract payload and key headers
const payload = $json.body || $json;
const headers = $json.headers || {};

// 2. Remove non-deterministic variables (signatures, dynamic timestamps)
const sanitizedHeaders = { ...headers };
delete sanitizedHeaders['x-signature-timestamp'];
delete sanitizedHeaders['authorization'];

// 3. Create deterministic SHA-256 hash from stringified sorted payload
function getDeterministicHash(obj) {
  const sortedKeys = Object.keys(obj).sort();
  const normalizedString = JSON.stringify(obj, sortedKeys);
  return crypto.createHash('sha256').update(normalizedString).digest('hex');
}

const idempotencyKey = headers['idempotency-key'] || getDeterministicHash(payload);
const traceId = `trace_${Date.now()}_${crypto.randomBytes(4).toString('hex')}`;

return [{
  json: {
    idempotencyKey,
    traceId,
    originalPayload: payload,
    metadata: {
      receivedAt: new Date().toISOString(),
      originIp: headers['x-forwarded-for'] || 'internal',
      contentType: headers['content-type']
    }
  }
}];

B. Exponential Backoff with Jitter Computation

When a downstream service fails, route the payload to this calculation node before pushing to the Redis delay pool:

// Inputs from execution metadata
const currentAttempt = ($json.metadata && $json.metadata.retryCount) ? $json.metadata.retryCount + 1 : 1;
const MAX_RETRIES = 5;
const BASE_BACKOFF_MS = 2000;
const MAX_BACKOFF_MS = 300000; // 5 minutes

if (currentAttempt > MAX_RETRIES) {
  return [{
    json: {
      ...$json,
      status: 'DLQ_EXHAUSTED',
      finalFailureReason: $json.lastError || 'Max retries exceeded',
      movedToDlqAt: new Date().toISOString()
    }
  }];
}

// Exponential Backoff: Base * 2^(attempt - 1)
const exponentialDelay = Math.min(MAX_BACKOFF_MS, BASE_BACKOFF_MS * Math.pow(2, currentAttempt - 1));

// Apply Full Jitter: Uniform distribution between 0.5 and 1.5
const jitterFactor = 0.5 + Math.random();
const finalDelayMs = Math.floor(exponentialDelay * jitterFactor);
const nextExecutionTime = Date.now() + finalDelayMs;

return [{
  json: {
    ...$json,
    status: 'PENDING_RETRY',
    metadata: {
      ...$json.metadata,
      retryCount: currentAttempt,
      nextExecutionTime,
      delayAppliedMs: finalDelayMs
    }
  }
}];

C. Atomic Redis Deduplication & Lock

Use an n8n Redis node configured with the Raw Command action to ensure the worker process doesn't duplicate executions:

SET webhook:lock:{{ $json.idempotencyKey }} "1" NX EX 86400

If the command returns null, the payload has already been ingested within the last 24 hours. The n8n router can short-circuit the execution immediately with a 200 OK (Duplicate Ignored), eliminating downstream race conditions.

4. Deployment, Performance & Failure Recovery

Handling High Concurrency in n8n

By default, n8n writes execution histories to its main database. When operating at peak loads, you must tune execution modes to avoid bottlenecking SQLite/PostgreSQL:

Set Execution Data Pruning:
Set EXECUTIONS_DATA_SAVE_ON_SUCCESS=none in your n8n environment variables to prevent your disk from filling up with successful 200-ACK payloads.
Enable Queue Mode:
Deploy n8n in Queue Mode using Redis as the broker. Decouple your webhook listener instances (Webhook Processors) from your Worker instances (Consumers).

# Production n8n environment variables configuration snippet
EXECUTIONS_MODE=queue
QUEUE_BULL_REDIS_HOST=redis-master.internal
QUEUE_BULL_REDIS_PORT=6379
N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
EXECUTIONS_DATA_SAVE_ON_ERROR=all
EXECUTIONS_DATA_SAVE_ON_SUCCESS=none
EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=72

The Automated Self-Healing Replay Pipeline

When downstream platforms recover from an outage, the Dead-Letter Queue contains hundreds of valid, pending payloads. Manually copying payloads out of log files is prone to human error.

The recovery engine handles this using a scheduled or trigger-based replay workflow:

Pulls batches from the Redis set webhook:dlq:dead via ZRANGEBYSCORE.
Verifies the target system's health via an HTTP OPTIONS/GET health-check endpoint.
Upon a valid 200 response from the target system, it resets retryCount to 0 and re-injects payloads directly into the primary consumer stream.
Idempotency guarantees (SETNX) ensure that partially completed side-effects are not duplicated.

5. Conclusion & Ready-to-use Workflow

Handling webhooks reliably requires moving away from fragile, synchronous direct-routing architectures. By introducing an in-memory Redis buffer with jittered exponential backoffs, metadata preservation, and automated dead-letter queueing, you can handle thousands of requests per second without losing business-critical data.

You can implement this system using the code snippets and architecture outlined in this article.

If you prefer a pre-built solution, you can get the production-ready package with test fixtures, container orchestration scripts, and end-to-end replay pipelines ready to import:

Instant Access on Whop: Download the Production Workflow
Direct Download on Gumroad: Download via Gumroad — use promo code EARLYBIRD for 20% off.

How I Built an Autonomous B2B Directory Scraping & Enrichment Pipeline with n8n and Python

Sun, 04 Oct 2026 14:24:28 +0000

How I Built an Autonomous B2B Directory Scraping & Enrichment Pipeline with n8n and Python

Modern web scraping for B2B intelligence has shifted. Three years ago, a static requests session combined with BeautifulSoup was sufficient for extracting structured company profiles from most business directories. Today, client-side hydration (Next.js, Nuxt), dynamic fingerprinting, and complex pagination patterns cause naive scrapers to fail silently or stall out.

At the same time, commercial data vendors charge thousands of dollars a month for stale directory dumps that lack real-time enrichment. In this guide, we break down an enterprise-ready, decoupled architecture: a headless Python extraction engine orchestrated by n8n, complete with recursive pagination, schema validation via Pydantic, and multi-destination ingestion.

1. The Bottleneck: Why Traditional Pipelines Break

Scraping production directories typically breaks across three operational vectors:

DOM Hydration & Anti-Automation Fingerprints: Modern directory listings defer rendering contact cards and metadata until specific micro-interactions occur (scroll events, viewport visibility). Standard HTTP clients pull empty HTML shells.
Orchestration Coupling: Embedding proxy rotation, retry backoff, browser pools, and CRM export logic inside a single monolithic Python script creates unmaintainable code. A single unexpected DOM variation halts the entire batch.
Schema Drift & Data Quality: Unsanitized scraped fields (inconsistent international dialing codes, obfuscated mailto links, malformed URLs) corrupt downstream analytics and CRM pipelines.

The Solution

Decouple extraction from orchestration:

Headless Worker (Python / Playwright): Runs in an isolated container, handles stealth browser contexts, executes JavaScript micro-scrolls, and extracts raw data.
Orchestration & State Management (n8n): Handles rate-limiting queues, recursive pagination states, failure retries with exponential backoff, and webhook dispatching.
Data Integrity Layer (Pydantic): Enforces strict types, normalizes phone numbers to E.164, extracts naked domains, and validates emails before storage.

2. System Architecture

   +-------------------------------------------------------------+
   |                      n8n Orchestrator                       |
   |  [Trigger] -> [Queue / Pagination Loop] -> [Webhook Dispatch]|
   +--------------+-------------------------------+--------------+
                  | HTTP POST                     ^
                  v                               | Clean JSON
   +-------------------------------+              |
   |  Python FastAPI + Playwright  |              |
   |  - Stealth context init       |              |
   |  - Scroll hydration           |              |
   |  - DOM query extraction       |              |
   +--------------+----------------+              |
                  | Raw Objects                   |
                  v                               |
   +-------------------------------+              |
   |   Pydantic Validation Layer   |--------------+
   |  - RFC Email validation       |
   |  - E.164 Phone formatting     |
   |  - Domain sanitization        |
   +-------------------------------+

Queue Trigger: n8n pulls an unvisited directory page URL from a PostgreSQL queue or a configured array.
Browser Context Execution: n8n sends a payload to the internal Python FastAPI worker (/scrape endpoint).
Extraction & Normalization: Playwright runs headlessly, extracts targets, runs records through Pydantic validators, and returns a verified JSON array.
Database Routing & Sync: n8n deduplicates records against existing primary keys and concurrently writes to PostgreSQL, Airtable, or your target CRM.

3. The Code & Core Logic

Step A: The Playwright Stealth Scraper (Python)

This worker exposes a lightweight FastAPI endpoint. It leverages Playwright with realistic user-agent headers, evasive navigator properties, and automatic waiting for selector hydration.

# worker.py
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel, HttpUrl
from playwright.async_api import async_playwright
import asyncio

app = FastAPI()

class ScrapeRequest(BaseModel):
    url: HttpUrl
    selector_container: str

@app.post("/extract")
async def extract_directory_page(payload: ScrapeRequest):
    async with async_playwright() as p:
        browser = await p.chromium.launch(
            headless=True,
            args=["--disable-blink-features=AutomationControlled", "--no-sandbox"]
        )
        context = await browser.new_context(
            user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36",
            viewport={"width": 1920, "height": 1080}
        )
        page = await context.new_page()
        
        try:
            await page.goto(str(payload.url), wait_until="networkidle", timeout=30000)
            
            # Trigger lazy loading by scrolling
            await page.evaluate("window.scrollTo(0, document.body.scrollHeight / 2);")
            await asyncio.sleep(1.2)
            await page.evaluate("window.scrollTo(0, document.body.scrollHeight);")
            await asyncio.sleep(1.0)
            
            cards = await page.query_selector_all(payload.selector_container)
            extracted = []
            
            for card in cards:
                name_el = await card.query_selector("h3.company-name")
                website_el = await card.query_selector("a.website-link")
                phone_el = await card.query_selector(".phone-display")
                
                extracted.append({
                    "raw_name": await name_el.inner_text() if name_el else None,
                    "raw_website": await website_el.get_attribute("href") if website_el else None,
                    "raw_phone": await phone_el.inner_text() if phone_el else None,
                })
                
            return {"status": "success", "total": len(extracted), "records": extracted}
        except Exception as e:
            raise HTTPException(status_code=500, detail=str(e))
        finally:
            await context.close()
            await browser.close()

Step B: Pydantic Validation & Normalization

Raw scraped data is notoriously messy. We enforce types and transform inputs into canonical shapes before the data reaches n8n:

# schemas.py
from pydantic import BaseModel, field_validator, HttpUrl
import re
from urllib.parse import urlparse

class CorporateRecord(BaseModel):
    company_name: str
    domain: str
    phone: str | None = None
    
    @field_validator("domain", mode="before")
    @classmethod
    def clean_domain(cls, v: str) -> str:
        if not v:
            raise ValueError("Empty website URL")
        v = v.strip().lower()
        if not v.startswith(("http://", "https://")):
            v = f"https://{v}"
        netloc = urlparse(v).netloc
        return netloc.replace("www.", "")

    @field_validator("phone", mode="before")
    @classmethod
    def normalize_phone(cls, v: str | None) -> str | None:
        if not v:
            return None
        digits = re.sub(r"[^\d+]", "", v)
        if len(digits) == 10 and not digits.startswith("+"):
            return f"+1{digits}"  # Standardize US numbers
        return digits if len(digits) >= 8 else None

Step C: n8n Dynamic Pagination & Deduplication Logic

In n8n, use a Code Node to manage state, calculate the next page offset, and filter out records that are already tracked in the database:

// n8n Code Node: Process Page Results & Generate Next Target
const response = $input.first().json;
const existingDomains = $('Check Existing Domains').all().map(item => item.json.domain);
const currentOffset = $node["Pagination Loop"].json.offset || 0;
const pageSize = 20;

// Deduplicate incoming batch against DB results
const validRecords = response.records.filter(record => {
  return record.domain && !existingDomains.includes(record.domain);
});

const hasMorePages = response.records.length === pageSize;

return {
  json: {
    validRecords: validRecords,
    nextOffset: currentOffset + pageSize,
    shouldContinue: hasMorePages,
    processedAt: new Date().toISOString()
  }
};

4. Deployment, Rate Limits, and Fault Tolerance

When running this architecture continuously, keep the following infrastructure practices in mind:

1. Handling Deadlocks & Stalled Instances

Playwright instances can occasionally freeze due to memory leaks on unhandled single-page apps. In Docker, configure strict container limits:

# docker-compose.yml snippet
services:
  playwright-worker:
    build: ./worker
    restart: unless-stopped
    deploy:
      resources:
        limits:
          cpus: '2.0'
          memory: 2048M
    environment:
      - PYTHONUNBUFFERED=1

2. Exponential Backoff in n8n

Inside the n8n HTTP Request Node that calls the extraction worker:

Set Retry on Fail to true.
Set Max Tries to 3.
Set Wait Between Tries to 5000 ms with dynamic jitter to avoid burst patterns against the target directory.

3. CRM Rate-Limiting

CRMs like HubSpot and Salesforce enforce strict rate limits (e.g., 100 requests per 10 seconds). In n8n, insert a Split In Batches node set to batch sizes of 10, combined with a Wait node set to 1.5 seconds, ensuring pipeline compliance without dropping records.

5. Conclusion & Ready-to-Use Workflow

By decoupling the raw Playwright browser execution from the higher-level workflow orchestration in n8n, you get a clean, fault-tolerant B2B extraction engine that scales without requiring commercial SaaS subscriptions.

You can implement this architecture manually using the snippets above, or deploy our production-tested, turnkey package that includes pre-configured n8n JSON templates, Docker Compose files, stealth driver scripts, and Pydantic validation models:

Instant Access on Whop: Get the Pipeline Template
Direct Download on Gumroad: Download on Gumroad — use promo code EARLYBIRD for 20% off.

Building a Sub-Minute Cross-Platform Inventory Sync Engine with n8n, Shopify, WooCommerce & Airtable

Sat, 03 Oct 2026 21:09:22 +0000

Building a Sub-Minute Cross-Platform Inventory Sync Engine with n8n, Shopify, WooCommerce & Airtable

Dual-channel e-commerce sounds great on a slide deck until an order drops simultaneously on Shopify and WooCommerce for your last unit of inventory. Within 45 seconds, you've oversold, triggered a support ticket, and compromised a customer relationship.

Most teams reach for commercial integration platforms (Zapier, Celigo, or specialized multichannel SaaS tools). Then they discover the fine print: tiered pricing based on order volume, 15-minute polling windows on entry tiers, or brittle two-way connectors that enter infinite webhook loops the moment inventory changes bounce back and forth.

In this technical breakdown, we will walk through engineering a self-hosted, bidirectional inventory synchronization engine using n8n and Airtable as an immutable Single Source of Truth (SSOT). This setup achieves sub-minute delta propagation, completely eliminates infinite sync ping-pong, and runs on your own infrastructure for pennies a day.

1. The Bottleneck: Why Commercial Multi-Channel Sync Breaks

Commercial sync services rely on two flawed primitives:

High-Frequency Polling: Checking platform APIs every 5–15 minutes introduces a massive latency window where stockouts happen invisibly.
Direct Point-to-Point Webhooks: Triggering an inventory adjustment on Shopify when WooCommerce updates creates an immediate echo loop unless state is cleanly managed.

Shopify Order Placed -> Webhook to WooCommerce -> WooCommerce Stock Drops
                                  ^                               |
                                  |--- Webhook to Shopify fires --|

Without an atomic central state orchestrator, platform A and platform B trade fractional updates until API rate limits throttle both endpoints or your SKU balances hit negative values.

Furthermore, direct multi-point sync burns through Shopify's REST/GraphQL leaky bucket limits (40 requests/sec for Plus, 2 requests/sec for standard) and WooCommerce's REST bottlenecks on unoptimized WordPress MySQL instances.

To solve this, we design a hub-and-spoke pipeline with Airtable acting as the lock-manager and single source of truth.

2. Architecture: Hub-and-Spoke with Atomic Locking

[ Shopify Webhook ]     --> [ n8n Ingestion Node ]
                                     |
[ WooCommerce Webhook ] --> [ Delta Sanitization Node ]
                                     |
                            [ State Check in Airtable (SSOT) ]
                                     |
                        +------------+------------+
                        | Is Delta Actual & New? |
                        +------------+------------+
                                     |
                      YES            |            NO (Echo Loop)
                       |             +-------------> [ Drop / Log Event ]
                       v
        [ Update Airtable Master Record ]
                       |
       +---------------+---------------+
       |                               |
       v                               v
[ Push to Shopify API ]    [ Push to WooCommerce API ]
       |                               |
       +---------------+---------------+
                       |
               [ Audit / Alerting ]

Pipeline Flow:

Webhook Ingestion: Changes trigger on orders/create, inventory_levels/update (Shopify), and woocommerce_rest_insert_product_review or product.updated (WooCommerce).
Lock Verification & Hash Matching: We compute a state signature hash(SKU + New_Quantity + Timestamp_Window) and verify if this event was initiated by our own sync engine.
Airtable Reconciliation: Fetch the canonical record via SKU. Check if Target_Qty !== Current_Master_Qty.
Batched Downstream Fanout: Broadcast the new inventory levels to counterpart endpoints using rate-managed chunks.
Audit Trail: Write an execution ledger entry. If stock hits <= 0, dispatch an alert to Slack/Discord.

3. The Code & Logic: Loop Prevention and State Normalization

Step 1: Normalizing Webhook Payloads (n8n Code Node / JavaScript)

Incoming payloads from Shopify and WooCommerce have completely different data shapes. We normalize both down to a unified schema inside an n8n Code Node.

// Ingestion Normalizer Code Node
const items = $input.all();
const output = [];

for (const item of items) {
  const json = item.json;
  
  let normalized = {
    source: '',
    sku: '',
    newQuantity: 0,
    syncOriginatorId: null
  };
  
  // Check if Shopify Payload
  if (json.inventory_item_id || json.available !== undefined) {
    normalized.source = 'shopify';
    normalized.sku = json.sku || $('Extract_SKU').first().json.sku;
    normalized.newQuantity = parseInt(json.available, 10);
    // Custom metadata check to prevent loops
    normalized.syncOriginatorId = json.sync_token || null;
  }
  // Check if WooCommerce Payload
  else if (json.stock_quantity !== undefined) {
    normalized.source = 'woocommerce';
    normalized.sku = json.sku;
    normalized.newQuantity = parseInt(json.stock_quantity, 10);
    normalized.syncOriginatorId = json.meta_data?.find(m => m.key === '_sync_originator')?.value || null;
  }
  
  if (normalized.sku) {
    output.push({ json: normalized });
  }
}

return output;

Step 2: Preventing Webhook Echo Loops (Loop Breaker Logic)

To prevent ping-pong updates, we compare the incoming update against the current state stored in Airtable. If the delta is 0 or originated from our system's active lock token, the execution terminates immediately.

// Conflict Resolution & Loop Suppression Node
const input = $input.first().json;
const masterRecord = $('Fetch_Airtable_SKU').first().json;

const currentMasterStock = parseInt(masterRecord.fields['Master_Stock'], 10);
const incomingStock = input.newQuantity;
const lastSource = masterRecord.fields['Last_Sync_Source'];

// Condition 1: Zero-Delta check
if (incomingStock === currentMasterStock) {
  return [{ json: { execute: false, reason: 'Zero delta: State already synchronized.' } }];
}

// Condition 2: Circular update check
// If the change came from the platform we updated less than 15 seconds ago
const lastSyncTime = new Date(masterRecord.fields['Last_Sync_Timestamp']).getTime();
const timeDifferenceSeconds = (Date.now() - lastSyncTime) / 1000;

if (input.source === lastSource && timeDifferenceSeconds < 15) {
  return [{ json: { execute: false, reason: 'Circular echo caught: Update originated from active sync window.' } }];
}

// Passed all checks: Safe to broadcast
return [{
  json: {
    execute: true,
    sku: input.sku,
    stockToSet: incomingStock,
    originSource: input.source,
    airtableRecordId: masterRecord.id
  }
}];

Step 3: Shopify GraphQL Inventory Adjustment Payload

Instead of clunky REST endpoints, use Shopify's modern inventorySetOnHandQuantities mutation to update stock instantly with an idempotent reference ID:

mutation InventorySetOnHand($input: InventorySetOnHandQuantitiesInput!) {
  inventorySetOnHandQuantities(input: $input) {
    inventoryAdjustmentGroup {
      id
      createdAt
    }
    userErrors {
      field
      message
    }
  }
}

Variables passed dynamically by n8n:

{
  "input": {
    "reason": "correction",
    "referenceDocumentUri": "gid://n8n-sync/{{ $json.originSource }}-{{ $now.toMillis() }}",
    "setQuantities": [
      {
        "inventoryItemId": "gid://shopify/InventoryItem/{{ $json.shopifyInventoryItemId }}",
        "locationId": "gid://shopify/Location/{{ $json.shopifyLocationId }}",
        "quantity": {{ $json.stockToSet }}
      }
    ]
  }
}

4. Deployment, Rate Limiting & Fail-Safes

When syncing catalogs containing thousands of SKUs during peak events (Black Friday, flash sales), naive setups trigger HTTP 429 rate limits or execution queue lockups.

1. Batching & Throttling in n8n

Split In Batches Node: Route bulk updates through batches of 25 items.
Wait Node: Configure a 250ms buffer between calls to respect Shopify's 2 req/sec standard REST baseline (or higher for GraphQL buckets).
Exponential Backoff: In n8n's HTTP Request settings, activate Retry On Fail (up to 3 attempts) with a wait between tries of 1000ms.

2. Guarding Against Negative Inventory States

Miscalculations can sometimes push numbers below zero. In your Airtable validation node, insert an alert boundary:

if ($json.stockToSet < 0) {
  // Route execution to an alert path
  return [{ json: { error: true, alertType: 'NEGATIVE_STOCK_ALERT', sku: $json.sku, attemptedVal: $json.stockToSet } }];
}

Connect this branch directly to a Discord or Slack node to notify the operations team before an overselling disaster takes place.

5. Conclusion & Ready-to-Use Workflow

By placing an intelligent mediator (n8n + Airtable) between Shopify and WooCommerce, you get:

Sub-minute sync speeds (typically < 3.2 seconds end-to-end).
Zero recurrent per-order sync costs.
Full architectural control with comprehensive audit logs and circular loop protection.

You can manually build this workflow in your own n8n instance using the schemas, GraphQL payloads, and Code Node logic detailed in this guide.

If you prefer to skip the boilerplate, configuration headaches, and test fixture construction, you can download the production-ready package—complete with preconfigured JSON workflows, Airtable base schemas, and edge-case routing:

Instant Access on Whop
Direct Download on Gumroad — Use promo code EARLYBIRD for 20% off.

Have questions on handling specific channel edge-cases or complex variant mapping? Drop a comment below!

Building a Full-Stack Micro-SaaS Inside n8n: Serverless Web Apps, DataTables & AI Image Pipelines

Fri, 02 Oct 2026 20:38:57 +0000

Most developers treat n8n strictly as an orchestrator for backend APIs—triggering on webhooks, transforming JSON, and sending Slack alerts.

However, by pairing n8n's Webhook node with the Respond to Webhook node, you can turn n8n into a complete serverless full-stack web application host. No Vercel, no Next.js deployment, no Docker frontend containers required.

In this deep dive, we'll examine how we built an entire AI Virtual Staging Micro-SaaS that lives 100% inside an n8n workflow—including:

Serving an interactive, responsive SPA with embedded Before/After comparison sliders.
Performing client-side HTML5 Canvas compression to prevent payload timeouts.
Implementing non-blocking asynchronous job polling using native n8n DataTables.
Enforcing architectural prompt guards to freeze room geometry in image-to-image AI pipelines.

Figure 1: Production pipeline output — empty Berlin Altbau listing photo (left) transformed into curated luxury staging (right) in ~33 seconds on Google Gemini compute.

🏗️ The Serverless n8n Web App Architecture

┌────────────────────────────────────────────────────────┐
│                   CLIENT BROWSER                       │
│  - Vanilla JS SPA (Served directly by n8n)            │
│  - HTML5 Canvas client-side compression (<3MB)         │
│  - Interactive Before/After slider                     │
└────────────────────────────────────────────────────────┘
          │ (1) GET /webhook/home-staging-form
          ▼
┌────────────────────────────────────────────────────────┐
│            n8n Webhook: "Page HTML"                    │───► Sends raw text/html; charset=utf-8
└────────────────────────────────────────────────────────┘
          │ (2) POST /webhook/home-staging-submit
          ▼
┌────────────────────────────────────────────────────────┐
│     Access Gate & Honeypot Validation                  │───► Validates PIN & daily quota
└────────────────────────────────────────────────────────┘
          │ (3) Returns { "jobId": "..." } immediately (<200ms)
          ▼
┌────────────────────────────────────────────────────────┐
│   Async Job Pipeline (Brain -> Gemini -> Drive)        │───► Asynchronous execution
└────────────────────────────────────────────────────────┘
          │ (4) Client polls /home-staging-status?jobId=...
          ▼
┌────────────────────────────────────────────────────────┐
│      Status Node: Reads from n8n DataTable             │───► Status: 'pending' -> 'done'
└────────────────────────────────────────────────────────┘

Pattern 1: Serving Full-Stack HTML Directly via n8n

To serve an entire web app from n8n without external static hosting:

Create a Webhook node set to GET on /webhook/home-staging-form with Response Mode: When Last Node Finishes.
Connect a Code node (Page HTML) that returns your HTML, embedded CSS, and vanilla JS application as a template literal string:

// Inside 'Page HTML' Code Node
const BRAND = {
  name: "Studio AI",
  colorPrimary: "#133b5c",
  colorAccent: "#2a6f97"
};

const html = `<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>${BRAND.name}</title>
  <style>
    :root { --primary: ${BRAND.colorPrimary}; --accent: ${BRAND.colorAccent}; }
    body { font-family: system-ui, sans-serif; display: flex; justify-content: center; }
    /* Interactive Before/After Slider CSS */
    .cmp { position: relative; overflow: hidden; cursor: ew-resize; }
    .cmp .before { position: absolute; inset: 0; clip-path: inset(0 calc(100% - var(--pos, 50%)) 0 0); }
  </style>
</head>
<body>
  <div class="card">
    <h1>${BRAND.name}</h1>
    <form id="f">
      <input type="file" id="photo" accept="image/*">
      <button type="submit">Transform Room</button>
    </form>
  </div>
  <script>
    // Client-side execution logic...
  </script>
</body>
</html>`;

return [{ json: { html } }];

Connect a Respond to Webhook node with:
- Respond With: text
- Response Body: ={{ $json.html }}
- Header: Content-Type: text/html; charset=utf-8

When visitors navigate to your n8n webhook URL, n8n responds instantly with a full graphical interface.

Pattern 2: Client-Side Compression Before Webhook Submission

Raw smartphone photos from real estate agents frequently exceed 12 MB to 20 MB. Uploading raw payloads directly to an automation webhook risks gateway timeouts (504) or memory spikes in the n8n container.

We solve this entirely in the browser using HTML5 Canvas before FormData is dispatched:

async function compressImage(file) {
  const bmp = await createImageBitmap(file, { imageOrientation: 'from-image' });
  const MAX = 2048;
  const scale = Math.min(1, MAX / Math.max(bmp.width, bmp.height));
  
  if (scale >= 1 && file.size < 3 * 1024 * 1024) return file;
  
  const canvas = document.createElement('canvas');
  canvas.width = Math.round(bmp.width * scale);
  canvas.height = Math.round(bmp.height * scale);
  
  const ctx = canvas.getContext('2d');
  ctx.drawImage(bmp, 0, 0, canvas.width, canvas.height);
  
  const blob = await new Promise(res => canvas.toBlob(res, 'image/jpeg', 0.88));
  return new File([blob], 'photo.jpg', { type: 'image/jpeg' });
}

This reduces 15 MB iPhone photos to under 1.8 MB in under 200 milliseconds, eliminating upload failures.

Pattern 3: Asynchronous Job Polling via Native n8n DataTables

Synchronous image generation calls take 15 to 30 seconds. Keeping an HTTP connection open between the browser and n8n for 30 seconds is fragile (cellular disconnects, proxy timeouts).

Instead, we implement a two-phase asynchronous job queue using n8n's native DataTables:

Submission (POST /home-staging-submit):
- The webhook receives the image and parameters.
- Generates an unguessable jobId (crypto.randomUUID()).
- Inserts a row into the staging_jobs DataTable: status = "pending".
- Immediately returns { "jobId": "..." } to the client in <200ms.
Background Processing:
- The workflow continues downstream without blocking the client.
- Brain node builds the AI prompt.
- Google Gemini edits the photo.
- Result is saved to Google Drive.
- Updates the DataTable row: status = "done", driveFileId = "...".
Client Polling (GET /home-staging-status?jobId=...):
- The browser polls every 4 seconds.
- A tiny webhook reads the row from DataTable and returns { "status": "done" }.
- Once "done", the browser fetches the image from /home-staging-image?jobId=... and activates the interactive slider.

Pattern 4: Strict Architectural Prompt Engineering (The Camera Lock)

When working with image-to-image models (like Google Gemini 3 Pro Image / Nano Banana Pro), models often hallucinate extra windows, alter wall geometry, or shift the camera angle. In real estate, an edited room that changes the physical architecture is legally unusable.

To prevent this, every dynamic prompt ends with an immutable Camera Lock Rule:

const cameraLock = " [FINAL HARD CONSTRAINTS - VERIFY BEFORE OUTPUT]: " +
  "This is an in-place edit of the input photograph. " +
  "1) Camera position, angle, framing, perspective, and focal length must be PIXEL-IDENTICAL to the input photo. " +
  "2) Room geometry is FROZEN: same walls, same ceiling, same windows, same doors, same floor area - never extend or reproportion the room. " +
  "3) Do NOT add ceiling-mounted or architectural elements: no extra windows, no fireplaces, no moldings. " +
  "4) Added furniture and decor must fit entirely WITHIN the space visible in the original photo.";

Because image generation models place heavier attention weights on final tokens, this prompt structure guarantees architectural fidelity.

Conclusion & Production Workflow

By combining webhook-served HTML, client-side Canvas optimization, and native n8n DataTables for polling, you can build production-grade, full-stack Micro-SaaS tools inside a single n8n workspace.

🐙 View Architecture & Documentation on GitHub
📦 Get the Full Production Agency Kit on Gumroad | Whop Instant Access (Use code EARLYBIRD for 20% off)

Have you used n8n to serve client-facing frontend apps? Share your architecture in the comments below!

SEO Automation with n8n: What to Automate Safely

Fri, 02 Oct 2026 15:50:00 +0000

SEO automation is safest when it collects evidence, applies repeatable rules, and asks a person to approve any change that could affect indexing, rankings, or published copy. n8n is useful for that middle layer. It can pull Search Console data, compare periods, filter noisy rows, log findings, and route a short review queue without being allowed to rewrite the site.

Partner disclosure. This guide includes a partner link to n8n Cloud. If you sign up through it, I may earn a commission at no extra cost to you.

That boundary matters. A workflow that says “these five pages lost impressions after a release” saves time. A workflow that changes five canonical tags because a metric moved can damage the site before anyone checks the reason.

Start with the native option

For an occasional check, use Search Console directly. Its Performance report already lets you filter by query, page, country, device, search appearance, and date. You can compare periods and export a table without building or maintaining a workflow.

n8n becomes useful when the work is recurring or needs more than one system:

run the same report every week;
compare a current window with a previous equivalent window;
ignore changes below a minimum impression threshold;
join SEO data with a release log or content inventory;
deduplicate alerts that have already been reviewed;
send different issues to different owners;
preserve an audit trail of what was detected and decided.

The automation should reduce repetitive preparation. It should not conceal how the decision was made.

Use a three-level safety model

Classify each SEO task before adding it to a workflow.

Level	Automation role	Examples	Default control
Observe	Read data and record facts	Search Console exports, sitemap checks, status monitoring	Can run unattended
Recommend	Apply rules and prepare a review queue	Flag falling pages, find sitemap mismatches, draft a title option	A person reviews the evidence
Change	Modify a public or indexable resource	Edit copy, redirects, canonicals, robots rules, internal links	Explicit approval plus rollback

Most small sites should keep their first SEO workflow in the first two levels. The potential gain from automatically changing a title is small compared with the cost of changing the wrong page or losing the original context.

What is generally safe to automate

Scheduled Search Console exports

Google provides a Search Analytics API for querying performance data. A request can group results by dimensions such as page, query, country, and device, and can apply filters before returning rows.

The API is not a complete event log. Google states that the service does not guarantee every row and returns top rows rather than all rows. Search Console also omits anonymized queries for privacy. Treat the export as strong first-party evidence with known limits, not an exhaustive ledger of every search.

Period comparisons with noise controls

A useful workflow can calculate:

click change = current clicks - previous clicks
impression change = current impressions - previous impressions
CTR change = current CTR - previous CTR

Do not alert on percentage change alone. A fall from two impressions to one is a 50 percent decline but is rarely a useful incident. Require a minimum volume and a meaningful absolute change.

review when:
current impressions >= 100
and absolute impression change >= 50
and percentage change <= -30%

Those values are starting rules, not universal SEO standards. Tune them to the size and volatility of the site.

Technical monitoring

n8n can schedule simple checks for:

important URLs returning a non-200 status;
sitemap URLs that redirect or fail;
canonical targets that no longer resolve;
a robots.txt or sitemap fetch that suddenly changes;
a critical page becoming unavailable;
a release list that does not match the expected public URLs.

Keep the monitor narrow: crawling every URL from a small n8n instance can overload the site, duplicate a proper crawler, or create false alarms from temporary rate limits.

Evidence packaging

The highest-value step is often the least dramatic one: build a review packet. Instead of sending “traffic down,” send:

affected URL;
metric and comparison windows;
absolute and percentage change;
minimum sample threshold;
recent release or content-change date;
current status code and canonical;
a link to Search Console for manual investigation;
the previous decision if the same issue was reviewed before.

That makes the alert actionable and keeps the workflow from pretending it knows the cause.

What should not run without review

Do not let a first SEO automation publish or change these items by itself:

titles, descriptions, headings, or body copy;
canonical tags;
redirects;
noindex, robots.txt, or crawl directives;
sitemap membership;
internal links at scale;
deletion or consolidation of pages;
repeated indexing requests;
AI-generated articles or local pages.

The same metric can have several causes. Falling clicks may reflect lower demand, a ranking change, a different result layout, a tracking issue, a migration, or a page that is intentionally targeting a narrower audience. A workflow can identify the symptom. It cannot infer the business decision from one number.

A safe weekly n8n workflow

The first version can use this sequence:

Schedule Trigger
  -> HTTP Request: Search Analytics API
  -> normalize rows
  -> compare with previous period
  -> apply volume and change thresholds
  -> check the alert ledger
  -> write a review record
  -> notify the owner

Step 1: choose equivalent periods

Compare like with like. A seven-day period can be compared with the previous seven days, but weekday patterns and holidays can still distort a small sample. For a low-volume site, 28-day windows are usually more stable. Record the exact dates because “last month” becomes ambiguous when somebody opens the alert later.

Step 2: query only the data you need

The Search Analytics API accepts a rowLimit from 1 to 25,000 and uses startRow for pagination. Google also warns that queries grouped or filtered by page and query can be more expensive against API load limits.

Start with the smallest useful query:

one search type;
one property;
only the required dimensions;
a bounded date range;
a row limit appropriate to the site.

Do not repeatedly query long historical ranges on every execution. Store completed period summaries and fetch only the window that needs updating.

Step 3: label preliminary data

Recent Search Console data can be incomplete. The API can return metadata showing that a result contains incomplete or still-processing data. A weekly report should either avoid the newest days or label them so a reviewer does not compare a final period with a preliminary one.

Step 4: normalize before comparing

Keep the comparison key explicit. If the workflow groups by page, normalize the public URL rules first but do not silently merge distinct pages. If it groups by query and page, remember that the available rows are still limited to the top data returned by Search Console.

Store raw input separately from calculated fields. That makes the result inspectable when a threshold behaves unexpectedly.

Step 5: prevent duplicate alerts

Create a stable key such as:

property + report_type + page + current_period_end

Before sending a notification, check whether that key is already in the alert ledger. Update an existing record when the evidence changes instead of creating a new task every time the workflow runs.

Step 6: notify, then wait for a decision

Send the review packet to email, Slack, Google Chat, Telegram, or the team’s normal task system. The notification should offer controlled outcomes such as investigate, accept as expected, create a content task, create a technical task, or snooze until more data exists.

For a workflow that must continue after a person responds, n8n can use a Wait step or an app operation that waits for approval. Record the reviewer, timestamp, and decision before any downstream action.

Example review logic

Finding	Workflow can do	Person must decide
Important URL returns 404	Capture response, timestamp, expected URL, and recent release	Restore, redirect, or intentionally retire
Sitemap URL redirects	List source and destination and check destination status	Update sitemap, redirect map, or page plan
Impressions fall 40 percent	Verify sample, compare periods, attach page and query rows	Whether demand, rankings, intent, or a site change caused it
Two pages appear for one query	Package page-level Search Console data	Whether intents differ or pages should be clarified or merged
CTR falls while impressions rise	Flag query and page combinations	Whether the snippet, ranking mix, or result layout explains it

When the finding concerns two competing URLs, use the full Search Console cannibalization diagnosis before changing either page. When a page is excluded, use the Crawled, currently not indexed decision guide rather than treating every exclusion as an error.

Add failure handling before trusting the report

The workflow itself needs monitoring. OAuth tokens expire, APIs return rate limits, schemas change, and a partial execution can send a misleading “all clear.”

Fail the report if the source request fails.
Record the number of source rows and filtered rows.
Distinguish “zero findings” from “no data received.”
Retry only temporary failures with a bounded policy.
Send exhausted failures to an Error Workflow.
Store the last successful run time.
Test with a known sample before scheduling production runs.

Use the failed n8n workflow debugging guide when a node fails, and add an n8n Error Workflow so a broken SEO report cannot fail silently.

Cloud or self-hosted n8n?

n8n Cloud is the simpler starting point for a small team because hosting, updates, and the workflow service are managed. Self-hosting can offer more infrastructure control, but it also makes backups, upgrades, security, uptime, and incident recovery your responsibility.

Choose based on operational responsibility, not on the SEO logic. The workflow should use least-privilege credentials either way. A read-only Search Console scope is preferable when the workflow only reads performance data. The n8n Cloud versus self-hosted cost guide compares the wider ownership trade-off.

A practical launch checklist

Begin with one property and one report.
Use read-only credentials.
Keep recent incomplete data out of final comparisons or label it.
Set minimum volume and absolute-change thresholds.
Store raw evidence and calculation inputs.
Deduplicate alerts.
Require a human decision for public site changes.
Add a rollback plan before automating any approved write.
Monitor the automation itself.
Review the rules after several real runs.

SEO automation is useful when it gives a person a shorter, better evidence queue. It becomes risky when the workflow converts an uncertain signal directly into a site change.

Sources checked

n8n partner link

Want managed n8n for the reporting workflow?

n8n Cloud is the simplest starting point if you want to build the reporting and approval logic without maintaining the workflow server. Affiliate disclosure: I may earn a commission if you sign up through this link, at no extra cost to you.

Try n8n Cloud

Need the SEO workflow mapped?

Send the property type, report frequency, decision threshold, and notification channel. I can map a read-only first version and define where human approval must remain.

Discuss the workflow

Originally published on FloxoLab.

Building for the Person Who Can't Debug It

Thu, 24 Sep 2026 13:19:38 +0000

This is the second half of a two-part writeup on an n8n lead-intake workflow.
Part1 covered the Webhook payload break — this one covers the rest of the build.

The first post about this workflow covered the Webhook payload break — the moment the Form Trigger got swapped out and every downstream reference silently pointed at data that no longer existed. That part's done. This is the rest of the build: three smaller decisions that don't share a bug, but do share a reason.

Marisol — the client this workflow was built for — isn't technical. She has no developer on call. If this breaks while she's using it, she's the one looking at it first. That fact didn't come up once and get filed away; it kept showing up, in places that had nothing to do with each other.

Flipping the IF Node

The junk filter was supposed to do one thing: stop a submission if both phone and email were empty, since a lead with neither is useless. The logic in my head was straightforward — "if phone empty AND email empty, stop."

But when I actually built the IF node, I flipped it: "if phone OR email is not empty, continue." Same condition, inverted. What changed was which branch reads as the main path. Written this way, the true branch is the branch I actually follow when I trace the workflow — the valid data moving forward. The false branch is just "nothing happens," which is exactly what it should look like: the door that quietly doesn't open.

It's a small thing. The workflow does the same job either way. But if Marisol — or anyone else — ever opens this node to understand why a lead didn't show up in Sheets, the condition should read like the thing that's actually happening, not like a double negative she has to mentally invert first.

Tested both directions: a submission with both phone and email empty correctly stopped, and a submission with just one filled correctly passed through.

Redesigning the Set Node

Originally, the Set node had exactly one job — default the message field to "No message provided" if it came in empty. That was true right up until the trigger swap.

Once the Webhook replaced the Form Trigger, the payload picked up a lot of extra weight — headers, params, webhookUrl, executionMode, all the raw HTTP metadata that comes bundled with a webhook request. None of it was useful to Sheets or Slack. All of it was now sitting in the same object as the five fields that actually mattered.

I could have left it. The extra keys wouldn't have broken anything downstream — Sheets and Slack only read what I told them to read. But that's exactly the kind of thing that's invisible until someone else has to look at it. So I rebuilt the Set node to do more: explicit mappings for all five clean fields — Name, Phone, Email, Service address, Message — stripping the noise and defaulting the message in the same place.

I chose explicit field mappings over n8n's "keep only set fields" toggle on purpose. The toggle does the same job with less typing, but it hides what's happening — you'd have to open the node and go find the setting to know why the extra fields disappeared. Written out explicitly, the five fields the workflow actually cares about are right there, visible, nothing to go dig for.

Writing the Doc for Marisol

The last piece was the plain-English explanation — the thing Marisol actually reads if something goes wrong. First time writing a doc like this, so I built it around what she'd need, not around what I found interesting to explain: what the workflow does, a step-by-step walkthrough using the real node names (Filter Out Junk Leads, Clean and Format Lead Data — the names she'd see if she ever opened it herself), and a troubleshooting section.

For troubleshooting, I didn't invent hypothetical failure cases — I used one that had actually happened. During testing, the Google Sheets node failed once because the credential needed reconnecting; disconnecting and reconnecting it fixed it. Small thing, but real, and more likely to recur than something exotic I could've made up instead.

The doc and the exported workflow JSON stayed as two separate files, deliberately. The JSON is the actual automation, importable straight into her n8n. The doc is a reference for a human. They don't get merged into each other — that split is what the brief asked for, and forcing them together would've made one file try to do two jobs.

Same Constraint, Three Places

None of these three decisions are related on the surface — an inverted condition, a redesigned node, a document. What ties them together is that each one got shaped by a person who wasn't going to be in the room the next time this workflow needed explaining, and who can't reason through n8n's internals if it breaks. The workflow doesn't get simpler because of that. It gets more legible.

More on how this and other builds come together: tarek-elzoghby.github.io/tarek-elzoghby-hub

n8n For AI Agent Workflows: Check The Execution Model Before The Node Catalog

Thu, 27 Aug 2026 06:55:08 +0000

Most of us have written the same glue between an LLM call, a vector store and half a dozen APIs more than once, and the pitch for any visual layer is that you stop rewriting it. If you are weighing that against another bespoke script, the first thing to check is not the node catalog, it is how the platform counts your work, because that number is what decides the bill at volume.

What n8n Is Underneath The Canvas

n8n is an open source automation platform built on a node based editor, where each node is an action: an API call, a transform, a message, a model inference. Workflows fire on webhooks, schedules, database changes or chat messages.

What separates it from the simpler tools is that you can drop into inline JavaScript or Python at any point in the graph. There are over 500 prebuilt integrations, and for anything without a node the HTTP Request node takes a raw curl command.

The Community Edition runs under a fair-code license. You self host it for free with unlimited executions, unlimited workflows and the full integration catalog. SSO, LDAP and audit logs are the parts behind a paid license.

The AI Agent Node Binds Other Nodes As Tools

The AI subsystem is built on LangChain, exposed as more than 70 visual nodes covering models, memory, chains, retrievers, vector stores, embeddings and output parsers.

The piece worth understanding is the AI Agent node. It is not a prompt template, it is a ReAct or OpenAI Functions agent with tool bindings, memory and an iterative reasoning loop. Any other n8n node can be bound as a tool, so the agent can query Postgres, hit an internal API or update a sheet as part of its own reasoning, and it picks which to call from context instead of following a path you hardcoded.

Model nodes cover OpenAI, Anthropic, Google, Mistral, Cohere and local models through Ollama. Swapping providers means swapping one node, the rest of the graph stays where it is.

Where The Execution Model Changes The Math

One execution is one complete workflow run, no matter how many nodes are in it. A 20 node workflow that runs once is one execution. Only successful runs count, so failed and test runs are free.

Put that next to per-task metering and the gap opens fast. Ten thousand runs of a ten step workflow is ten thousand executions here, and one hundred thousand tasks on a platform that bills each step. n8n Cloud Pro is 60 euros a month for ten thousand executions. Self hosting the same load costs a VPS, roughly four to seven dollars a month, because the execution ceiling disappears entirely. The full breakdown of the AI nodes, RAG setup and pricing tiers walks through where each path stops making sense.

Running The Whole Stack Locally

The Self-Hosted AI Starter Kit is a Docker Compose template that bundles n8n with Ollama for local models, Qdrant for vectors and PostgreSQL for data and conversation memory, in one command.

There are profiles for NVIDIA and AMD GPUs, a CPU only profile for testing, and on a Mac you run Ollama natively and point the containerized n8n at it. It is Apache 2.0, separate from the fair-code license on n8n itself, so there is nothing to negotiate around commercial use.

That gets you RAG pipelines, agents with persistent memory and local document processing without a single call leaving the machine, which is the part that matters if you are working under data sovereignty rules.

The Takeaway

Node count is the least interesting number on the page. What you actually want to know before committing a workflow to production is what the platform counts as one unit of work, when that count resets, and whether removing the ceiling is a matter of running it yourself. On n8n all three answers are good, and that is the reason it keeps showing up in agent stacks that started out as scripts.

Senior AI Engineer Available for Freelance, Consulting & Long-Term Projects

Wed, 05 Aug 2026 20:26:54 +0000

Over the past few years, I've been building production-grade AI applications, full-stack web platforms, and intelligent automation systems for startups and businesses across different industries.

My expertise includes:

🤖 LLM applications, AI agents, and RAG systems
⚡ AI workflow automation (n8n, APIs, MCP, integrations)
🐍 Python, FastAPI, Next.js, React, TypeScript
🧠 Multi-agent architectures and structured AI pipelines
☁️ Cloud deployment, scalable backend systems, and DevOps
🔗 Third-party integrations, payment systems, CRMs, and business automation

Some of the projects I've delivered include AI-powered assistants, healthcare platforms, automation systems, digital products, travel platforms, marketing websites, and custom business solutions.

I focus on building systems that are:

Reliable in production
Scalable and maintainable
Performance-oriented
Designed around real business outcomes—not just prototypes

Whether you need to build an AI product from scratch, integrate LLM capabilities into an existing application, automate business workflows, or modernize a web platform, I can help turn ideas into production-ready solutions.

If you're looking for an experienced engineer for freelance work, contract projects, technical consulting, or a long-term collaboration, I'd be happy to connect.

📩 Feel free to reach out if you have an interesting project or are looking for a technical partner.

Portfolio Demo: https://www.loom.com/share/dd792a043d6b4d4483adba463bbe02f3

Four reliability problems no-code automation hands back to you in production

Mon, 13 Jul 2026 11:07:16 +0000

I run our entire content pipeline on self-hosted n8n: ten workflows, around 209 nodes, on one small box, turning trend signals into scripts, voiceovers, rendered videos, and scheduled posts every day. The visual canvas is genuinely good, and for the first hour it feels like automation is a solved problem — you drag in a trigger, wire up some nodes, and the happy path just works.

Then it runs a few thousand times, and you discover the thing no-code tools quietly don't tell you: production automation is a distributed-systems problem, whether or not you called it that. The moment a workflow makes network calls, writes to a database, or posts to an external service, you inherit the same hard questions a hand-written backend would — and a visual builder makes the happy path free while handing the rest straight back to you.

Here are the four that bit us, and how you actually deal with them. None of this is a knock on n8n specifically; it's honest about giving you the primitives. It just doesn't solve these for you.

1. Retries aren't free — you need idempotency

Every serious automation tool has a "retry on failure" toggle, and n8n's is one setting per node. It feels like a safety net. It's a trap if you don't think about it.

The problem is at-least-once delivery. If a node posts to a social scheduler, then the next node fails and the run retries from a checkpoint — or you re-trigger the workflow to recover — the post fires twice. The retry doesn't know the side effect already happened. Anything non-idempotent (publishing, sending, charging, inserting a row) will happily run again.

The fix is the same one you'd use in any backend: make the side-effecting step idempotent, or guard it with state. We put a status column in front of the non-idempotent steps, so a step is a no-op if it already ran:

// n8n Code node, before a publish step
const row = $input.item.json;
if (row.status === 'published') {
  // already sent — don't double-post on a retry/retrigger
  return [];
}
// ... do the publish, then flip status = 'published' in the next node

It's a boring pattern, but the visual canvas won't suggest it, because from the canvas's point of view a retry is just "run the node again."

2. Partial failure needs an explicit path you have to build

The happy path is a straight line you can see. The failure path is invisible until you draw it — and by default, a step that throws just stops that one execution, silently, wherever it happened to be.

Two rules keep this sane for us. First, a dedicated error workflow: n8n lets you point every workflow at one error handler, so we run a small four-node "heartbeat" that catches any failure anywhere in the pipeline and pings our team chat with which workflow died and why. Nothing fails in the dark.

Second, and this is a policy more than a feature: no silent fallbacks. When a step can fail, we let it fail loudly — it throws and propagates, it does not quietly return a cheaper or emptier result that looks like success. A silent fallback is how you end up shipping an empty render or a half-built post and finding out from a viewer. If a call fails, the run turns red and the heartbeat tells us. Loud failure is a feature.

3. Concurrency and ordering are yours to enforce

This is the one that surprised me most, because it's not about any single node — it's about two workflows sharing a resource.

Part of our pipeline drives headless Chrome to render frames. On a small box, two of those running at once will fight over memory and fall over. n8n has no idea these two workflows contend for the same physical resource; it'll happily fire both when their triggers line up.

So we reach outside n8n for the coordination: the render steps take a Postgres advisory lock before touching Chrome, and release it after, so only one render runs at a time and the rest queue behind it. The lesson generalizes — any shared external resource (a rate-limited API, a single-writer file, a GPU) needs a lock or a queue the workflow engine doesn't know about and won't create for you. If ordering matters, you own it.

4. Data-shape drift fails silently

The last one is the quietest. n8n's Postgres node returns JSONB columns as real JS arrays and objects, which is lovely — until a SELECT omits one of those columns. Then a downstream Code node doesn't see an empty array; it sees undefined. And a guard like if (row.scenes.length === 0) doesn't return "empty" — it throws, or worse, a row.scenes?.length check passes as "fine" and you process a record that's actually missing its data.

We got bitten when a fetch query didn't include every JSONB field a later validator read. The fix is unglamorous: select every field your validators touch, and assert the shape at the boundary with an If node before you trust the data, exactly like you'd validate an API response you didn't control. Treat the previous node's output as untrusted input, because across a few thousand runs, eventually it is.

The honest takeaway

None of this makes n8n a bad tool — the opposite. It's why we picked it over a fully-hosted no-code option: it gives you real Code nodes, error workflows, and the escape hatches to solve all four of these properly. That's also exactly why it's the wrong tool for someone who wants automation to "just work" on day one without thinking about idempotency or locks — the same power that lets you fix these problems is the power that makes you responsible for them.

If you want the fuller picture of where that trade-off lands — the learning curve, the self-hosting ops burden, the per-execution billing that made it worth it for us at volume — I wrote it all up in my hands-on n8n review after running it in production. But the short version is the lesson above: no-code buys you the happy path for free, and production is where you pay for the rest.

I built a cryptographic audit trail for AI agent decisions — now a verified n8n node

Wed, 01 Jul 2026 07:50:02 +0000

AI agents are making real decisions: approving loans, releasing payments, flagging insurance claims, modifying customer records. When something goes wrong, there's usually no tamper-evident record of what the agent decided, why, and under which policy.

I built Signatrust to fix that.

How it works:
Every agent decision → sealed into a Decision Receipt → Ed25519 signature + SHA-256 hash chain → append-only ledger. Any third party can verify the receipt independently without touching your systems or seeing your raw data.

What's available now:

✅ Verified n8n node: n8n-nodes-signatrust (install from Community Nodes)
📦 PyPI: pip install langchain-signatrust / crewai-signatrust
📚 24 ready-to-import n8n workflows (finance, insurance, HR, healthcare, GDPR)
📜 Open spec (ADR v1.0): signatrust.net/adr
🆓 Free tier, no account needed to verify receipts

Links:
→ github.com/abokenan444/n8n-signatrust-workflows
→ signatrust.net
→ npmjs.com/package/n8n-nodes-signatrust

Would be curious to hear: are you building AI agents that touch regulated or high-stakes decisions? How are you handling the audit trail today?

Installing and Configuring n8n on a Raspberry Pi (Private Home Server)

Mon, 23 Mar 2026 15:01:38 +0000

title: Installing and Configuring n8n on a Raspberry Pi (Private Home Server)
published: true
date: 2026-03-23 14:49:52 UTC
tags: raspberrypi,n8n,ai,aiagent

canonical_url: https://medium.com/@mahinshanazeer/installing-and-configuring-n8n-on-a-raspberry-pi-private-home-server-2ce086e7408b

GitHub - mahinshanazeer/n8n-home-server: Installing and Configuring n8n on a Raspberry Pi (Private Home Server)

Introduction

Automation is becoming a core part of modern workflows, whether for DevOps, personal productivity, or integrations. n8n is a powerful, open-source workflow automation platform that allows you to create custom integrations with full control over your data.

In this guide, we will set up n8n on a Raspberry Pi using Docker, configured for private network access (no domain, no SSL) — ideal for home labs.

Why Self-Host n8n on Raspberry Pi?

Low-cost, always-on device
Full data privacy (no third-party cloud dependency)
Perfect for home lab and DevOps experimentation
Lightweight yet powerful automation engine

Prerequisites

Ensure the following are ready:

Raspberry Pi (Pi 4/5 recommended, 4GB+ RAM)
Linux OS (Ubuntu Server / Raspberry Pi OS Lite)
Docker & Docker Compose installed
Static private IP (recommended)

Project Structure

We will keep everything inside a single directory:

~/n8n/
├── .env
├── docker-compose.yml
├── n8n-data/
└── local-files/

directory structure

This approach ensures:

Easy backup
Clean portability between systems
Full control over persistent data

Step 1: Create Project Directory

mkdir -p ~/n8n && cd ~/n8n
mkdir n8n-data local-files

Step 2: Create Environment Configuration

Create a .env file:

nano .env

Add the following:

N8N_HOST=192.168.1.200
N8N_PORT=5678
N8N_PROTOCOL=http

WEBHOOK_URL=http://192.168.1.200:5678/

GENERIC_TIMEZONE=Asia/Kolkata

N8N_SECURE_COOKIE=false

Key Notes:

N8N_HOST → Your Raspberry Pi private IP
WEBHOOK_URL → Required for workflows
N8N_SECURE_COOKIE=false → Mandatory for HTTP access

Step 3: Create Docker Compose File

Create docker-compose.yml:

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    container_name: n8n
    restart: always
    ports:
      - "5678:5678"
    environment:
      - N8N_HOST=${N8N_HOST}
      - N8N_PORT=${N8N_PORT}
      - N8N_PROTOCOL=${N8N_PROTOCOL}
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=${N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS}
      - N8N_SECURE_COOKIE=${N8N_SECURE_COOKIE}
      - NODE_ENV=${NODE_ENV}
      - WEBHOOK_URL=${WEBHOOK_URL}
      - GENERIC_TIMEZONE=${GENERIC_TIMEZONE}
      - TZ=${GENERIC_TIMEZONE}
    volumes:
      # n8n data: SQLite database and encryption key
      - ./n8n-data:/home/node/.n8n
      # Shared files between n8n and host (use /files path inside n8n)
      - ./local-files:/files

Step 4: Start n8n

docker compose up -d

Verify:

docker compose ps

Step 5: Access n8n

Open in browser:

http://192.168.1.200:5678

home page

Create your admin account
Start building workflows (will create another blog on building workflows)

Common Issue (Important)

You may see:

“Your n8n server is configured to use a secure cookie…”

Fix:

Set in .env:

N8N_SECURE_COOKIE=false

Restart:

docker compose down
docker compose up -d

Data Persistence

All important data is stored in:

~/n8n/n8n-data

This includes:

Workflows
Credentials
SQLite database

Github: https://github.com/mahinshanazeer/n8n-home-server

Stop Coffee Over Excel: Your 100% Automated "Daily Merchant Morning" with PrestaShop and AI ????

Fri, 20 Mar 2026 03:32:22 +0000

It’s 7:55 AM. You have your coffee in hand. You open your computer, log into your PrestaShop back office.

Click on “Dashboard”. Click on “Orders”. Click on “Stats”. You filter on “Yesterday”. You try to remember if the number is better than last Tuesday. You check the inventory…

Stop. ????

We all know this ritual. It’s reassuring, but it’s terribly passive. What if I told you that while you were still sleeping, an Artificial Intelligence has already scanned your store, analyzed your sales, detected an abnormal volume drop, and prepared a complete strategic briefing in your mailbox?

This isn’t science fiction. This is what I call the “Daily Merchant Morning”.

Today, I’m going to show you how to build this system. Not with complex systems or expensive custom developments, but with a modern, elegant, and formidable stack: n8n, AI, and the standard that’s changing everything: the MCP protocol.

Part 1: The Problem Isn’t Data, It’s Attention

As a developer and e-commerce expert, I make a simple observation: the modern merchant doesn’t lack data, they lack clarity.

PrestaShop is full of information. But transforming these order lines into business decisions takes time.

“Did my promotion yesterday work?”
“Why is my average cart declining?”
“Which products will be out of stock in 48 hours?”

Until now, to answer these questions automatically, you had to:

Either pay for prohibitively expensive B.I. (Business Intelligence) tools.
Or ask a developer to create complex CSV exports or fragile API scripts.

But the arrival of LLMs (Large Language Models) and Low-Code automation tools like n8n is changing the game. We can now create Agents capable of reasoning about data.

The technical challenge was the connection. How to connect “the brain” (ChatGPT) to “the memory” (PrestaShop) in a simple and secure way?

That’s where the Model Context Protocol (MCP) comes in.

Part 2: Decrypting the MCP Architecture (The Secret of Fluidity)

Forget classic REST APIs where you have to code each request (GET /orders?date=yesterday...). With MCP, we enter the era of tooled AI.

To build our “Daily Merchant Morning”, we need a precise architecture on the PrestaShop side. It’s like a two-stage rocket:

1. The Foundation: PrestaShop MCP Server ????️

This is the essential foundation. Developed by the PrestaShop Team (and free on Addons), this module transforms your store into an “MCP Server”.

Concretely? It opens a secure and standardized door. It manages authentication and allows an AI agent to connect to your store without you having to manually manage complex OAuth tokens.

This is the pipe.

2. The Fuel: MCP Tools Plus ⚡

Once the pipe is laid, you need to pass interesting things through it. The base server is great, but for advanced business analysis, we need specific tools.

That’s where MCP Tools Plus comes in. It plugs into the server to add advanced “Tools” that the AI can call:

get_advanced_sales_stats: To get revenue, average cart, Y-1 comparison.
get_best_sellers: To identify yesterday’s star products.
analyze_stock_levels: To spot logistics emergencies.

It’s this combination of Infrastructure (PrestaShop) + Intelligence (Tools Plus) that makes the system super powerful.

Part 3: Putting It Into Practice (Your n8n Workflow)

Let’s get concrete. Here’s how I orchestrated all this in n8n.

The goal: Receive an HTML-formatted email every morning at 7:00 AM.

The Workflow at a Glance

The diagram of my current workflow

Here’s the mechanism, step by step:

Step 1: The Wake-Up Call (Schedule Trigger)

Nothing fancy here. A cron node configured for Every Day at 07:00. Regularity is the key to ritual.

Step 2: The Brain (AI Agent + MCP Client)

This is where the magic happens.

I use an AI Agent node (connected to OpenAI GPT-4o or a powerful model). But careful, I don’t just give it text. I attach a “Tool” via the MCP Client node.

In the MCP Client configuration, I simply enter the credentials provided by the PrestaShop module.

The beauty of it? I don’t need to tell the AI how to fetch the revenue.

My system prompt looks like this:

You are an E-commerce expert. Use the tools at your disposal to retrieve yesterday's sales.
Compare them to the same day last week. Identify products with stock alerts.
Write a summary report in HTML format.

The AI will decide on its own: “Well, to answer Nicolas, I’ll use the get_sales_stats tool from the MCP Tools Plus module.”

Step 3: The Result (Gmail)

The agent returns a perfectly structured HTML block. I just pass it to the Gmail node to send it.

The Final Result

And here’s what arrives on my phone when I wake up:

The morning email rendered by AI

Look at the level of detail:

Dynamic KPIs: Revenue variation, average cart.
Semantic Analysis: The AI wrote: “Good, but not enough. Volume is declining…“. It interprets the numbers!
Priority Actions: It suggests to “Boost acquisition on Top 3”. It becomes a proposing force.

Part 4: Vision & Future Impact ????

What we just saw goes beyond a simple technical gadget. It’s a paradigm shift for us, developers and e-merchants.

1. The developer’s role evolves.

We’re no longer just “code writers” creating rigid modules. We become orchestrators. Our added value lies in our ability to connect intelligent blocks (PrestaShop, MCP, AI) to create value flows.

2. Commerce becomes proactive.

With this type of workflow, the merchant no longer suffers through their day. They attack it with a battle plan generated based on real data. We move from “Statement” to “Action”.

3. Technical accessibility.

Thanks to MCP, AI “understands” your store. Tomorrow, this workflow can be adapted to:

Automatically respond to customer reviews.
Generate product descriptions based on your best sellers.
Reorganize your homepage based on yesterday’s trends.

The possibilities are infinite, and the technical barrier has never been lower.

Conclusion: Get Ahead

Automation isn’t here to replace the merchant, but to give them back the most precious resource: their available brain time.

Setting up this “Daily Merchant Morning” means getting yourself a senior data analyst assistant, available 24/7, for the price of a few API tokens.

???? Want to Set This Up Tomorrow Morning?

I know that configuring n8n, finding the right prompts to get a nice HTML table, and adjusting MCP connections can be intimidating if it’s your first time.

To save you time, I’ve exported my complete n8n Workflow (JSON file).

It’s ready to use. It contains:

✅ The complete flow structure.
✅ The advanced System Prompt (optimized for e-commerce analysis and HTML rendering).
✅ Pre-configuration for MCP Tools Plus tools.

To get started, just follow these 3 steps:

Install the free PrestaShop MCP Server module to secure the connection.
Add the MCP Tools Plus module to unlock AI analysis tools.
Download the JSON file below and import it into n8n.

???? Need to Host n8n on a VPS?

If you’re looking for where to host your n8n workflows reliably and affordably, Hostinger offers high-performance VPS with excellent value for money. That’s actually where some of my own automation workflows run. The interface is intuitive, deployment is quick, and you can easily install n8n on their infrastructure. By using my referral code, you get -20% on your first hosting.

???? Download the “Daily Merchant Morning” JSON Workflow here

Your turn. Make your store work for you, not the other way around!

Did you like this article? Share it with an e-merchant friend who spends too much time on Excel! ????

How I Built a Programmatic SEO Machine for n8n Workflows with Next.js

Fri, 16 Jan 2026 04:54:15 +0000

"If you build it, they will come." ...Well, not really. Not if Google doesn't know you exist.

I've been building n8nworkflows.world, a search engine for n8n automation templates. My goal was simple: make it easier to find high-quality, verified n8n workflows than the official forums.

But I hit a wall. People don't just search for "n8n workflows". They search for specific problems:

"How to save Telegram files to Google Drive"
"Notion to Slack automation"
"Postgres to Google Sheets sync"

To capture this traffic, I needed a landing page for every single possible integration combination. Writing them manually would take years.

So, I used Next.js and Programmatic SEO (pSEO) to generate 2,800+ pages overnight. Here is the technical breakdown of how I did it.

1. The Architecture ️

The stack is simple but powerful, designed for speed and SEO:

Frontend: Next.js 14 (App Router)
Database: Supabase (PostgreSQL)
Data Processing: Python (for analyzing JSON relationships)
Hosting: Vercel

2. The Data Problem: Extracting Relationships

I started with a database of 6,000+ n8n workflow JSON files. To generate useful pages, I needed to understand "what connects to what".

I wrote a Python script to parse these JSONs and extract "Node Pairs". For example, if a workflow contains a Telegram Trigger node and a Google Drive node, that creates a relationship: telegram-to-google-drive.

I stored these pairs in a separate Supabase table integration_pairs with metadata:

slug: "telegram-to-google-drive"
app_a: "Telegram"
app_b: "Google Drive"
count: 42 (number of workflows using this pair)

3. Implementation: Dynamic Routes in Next.js

This is where Next.js shines. Instead of creating 2,000 physical files, I used Dynamic Routes.

I created a folder structure like this: app/integration/[slug]/page.tsx

Here is a simplified version of the code:

// app/integration/[slug]/page.tsx

import { createClient } from '@/utils/supabase/server';
import { notFound } from 'next/navigation';

export async function generateMetadata({ params }) {
  // Auto-generate SEO titles based on the URL slug
  // Example: "Best Telegram to Google Drive n8n Workflows"
  const pair = params.slug.replace('-', ' to ');
  return {
    title: `Best ${pair} n8n Workflows & Templates (Free Download)`,
    description: `Discover verified automation templates to connect ${pair}. Download free JSONs.`
  };
}

export default async function IntegrationPage({ params }) {
  const { slug } = params;
  
  // 1. Fetch workflows that match this specific pair
  const workflows = await getWorkflowsByPair(slug);

  if (!workflows) return notFound();

  return (
      <div className="container mx-auto py-10">
        <h1 className="text-4xl font-bold mb-6">
            {slug.split('-').join(' ')} Integrations
        </h1>
        
        <p className="text-gray-400 mb-8">
            Browse {workflows.length} verified templates to automate your work.
        </p>

        <div className="grid grid-cols-1 md:grid-cols-3 gap-6">
          {workflows.map(wf => (
             <WorkflowCard key={wf.id} data={wf} />
          ))}
        </div>
      </div>
  );
}

4. The Result: A Massive Directory Map

To help Google crawl these pages, I built a massive Directory Index. It lists every single combination alphabetically.

By deploying this structure, I achieved three things:

Scalability: If I add a new workflow that connects "DeepSeek" to "Whatsapp", the page /integration/deepseek-to-whatsapp is created automatically.
Long-tail Traffic: I am now indexing for specific queries that have low competition but high intent.
Better UX: Users can find exactly what they need without digging through forums.

5. Going Further: The "Google Opal" Experiment

Since the pSEO architecture was already in place, I recently expanded it to cover Google Opal (Google's new AI app builder).

I realized there was no gallery for Opal templates yet. So, I scraped the top 25 prompts and generated a new section on the site in just one weekend.

This proves the power of a flexible Next.js + Supabase architecture. You can spin up new "verticals" for your project incredibly fast.

Conclusion

Building a directory doesn't have to be manual work. With Programmatic SEO, you can leverage your existing data to create thousands of helpful entry points for your users.

You can check out the live result and the directory structure here: n8nworkflows.world

Happy coding!

Automate GitHub Issues with AI and n8n to Get More Time for Coding

Mon, 13 Oct 2025 11:41:14 +0000

When I first read the now famous tweet from Joanna Maciejewska

I want AI to do my laundry and dishes so that I can do art and
writing, not for AI to do my art and writing so that I can do my
laundry and dishes.

I could not agree more. I love writing code and I do not want AI to take over what I enjoy so much. But I would like AI to do the boring stuff that is part of a developer’s day-to-day life. If you know me, then you probably know that I like to keep the number of meetings to a bare minimum, and I do not like spending a lot of time on triage, planning, and retrospectives. So when I first heard about the n8n automation tool, my immediate thought was to see if it could handle GitHub issue triage, using AI to do the thinking part.

TL;DR: Yes, it can and it is easy to set up.

What is n8n

n8n is an open-source workflow automation tool that lets you wire up APIs and services without spending hours reinventing the wheel. It has built-in nodes for things like GitHub, Slack, Jira, Google Drive, Notion, and many, many more, but you can also drop down to raw HTTP requests or custom functions when you need control or something custom. It lets you automate things quickly, so you don’t waste hours writing all the code yourself.

Plus, n8n comes with an intuitive drag-and-drop interface that makes the whole process even easier and more straightforward. You can visually design workflows, connect nodes with a simple drag, and see exactly how the entire workflow looks.

The plan

Let’s first lay down the overall plan and then elaborate more on each step once we get there.

Set up n8n locally.
Create a GitHub repository and prepare some issues.
Create the workflow logic
- Fetch all GitHub issues that need triaging.
- Send a prompt to AI for each issue with detailed instructions on how to perform the triage and what data to extract (labels and summary).
- Update each GitHub issue with the labels and summary returned by the AI.

Setting up n8n

Getting started is straightforward with the official documentation on how to get started. You can use n8n Cloud (they offer a free tier) or run a self-hosted version. If you just want to experiment, I recommend the self-hosted option: pull the Docker image and run it locally. Later, if you decide to deploy it more seriously, the documentation covers Docker Compose and Kubernetes setups.

Setting up GitHub repository

First we will need to create a GitHub repository and several issues so we can test the idea. I created a demo repository with 6 issues. My idea was that when the issue is created, it will get the `needs-triage label (this part is handled by GitHub workflow and it is part of the repository), so the automation can target only those and we do not triage the same issues multiple times.

Since I am now just trying to verify my idea, I kept the issue description minimal and just made sure that they are diverse.

After the automated triage I want to sort my issues and assign to each a type, priority and complexity label.

type: bug, enhancement, question, documentation or tech-debt
priority: priority: high, priority: medium or priority: low
complexity: good-first-issue, regular or complex

The automation flow will be:

get all GitHub issues with needs-triage label
let AI analyze them and assign labels and generate a short summary of the issue
update the labels on GitHub

You will need to create a GitHub Personal Access Token with repo permissions (the token needs to be able to read and update issues) and and API token for the AI node - I will use OpenAI.

So let’s start building it up!

Workflow Trigger

There is a Schedule Trigger node that allows us to schedule an execution daily, weekly, etc. I decided to also use When clicking 'Execute workflow' trigger node so I can test the flow easily.

Fetching Issues from GitHub

The next step is fetching issues from GitHub with the needs-triage label. Luckily n8n has already build-in GitHub integration, so just search for GitHub and then select Get issues of a repository. My node configuration looks like this:

And we just connect the node to the trigger(s).

Triage Logic Implementation

The GitHub node returns all the issues, so now we need to configure the workflow so it:

loops through the items
for every item it uses the AI to do the triage
update the labels on GitHub

So let’s first add the Loop over Items node and set the batch size to 1 (because we will be handling items one by one). And after our loop node we connect the Open AI Message a model node. Select your API key and which model you want to use (I used the GPT-5 model).

The most important part is the prompt. Here is the prompt I used - at the end you can see me passing the actual title and body of the issue we are currently looping.

You are a GitHub triage assistant. 
Given the title and body of a new issue, return a JSON object with the following keys:

{
  "type": "bug | enhancement | question | documentation | tech-debt",
  "priority": "priority: high | priority: medium | priority: low",
  "complexity": "good-first-issue | regular | complex",
  "summary": "<short summary of the issue in less than 50 words>"
}

Rules:
1. Type classification:
   - "bug" = broken functionality.
   - "enhancement" = feature request or improvement.
   - "question" = user inquiry or clarification.
   - "documentation" = docs-related issue.
   - "tech-debt" = refactoring, internal cleanup, maintenance tasks.
2. Priority classification:
   - High = critical or urgent.
   - Medium = important but not urgent.
   - Low = minor, trivial, or cosmetic.
3. Complexity classification:
   - "good-first-issue" = simple, well-defined, easy for a new contributor (e.g., styling, copy changes, small fixes). Priority is NOT high.  
   - "regular" = standard issue that requires some experience or understanding of the codebase.  
   - "complex" = difficult issue, may involve multiple components, advanced knowledge, or high-risk changes.
4. Summary should be concise (<50 words).
5. Return valid JSON ONLY, no extra text.

Example input:
Title: "Fix typo in README"
Body: "There's a small typo in the installation instructions."

Example output:
{
  "type": "documentation",
  "priority": "priority: low",
  "complexity": "good-first-issue",
  "summary": "Correct typo in README installation instructions."
}

Now classify this issue:
Title: {{$json["title"]}}
Body: {{$json["body"]}}

Tip: Don’t be afraid to use an AI tool to help you generate the prompt itself.

So our flow now looks like this:

Now we come to the more technical part. The AI node returns only the labels and summary for each issue, but in order to be able to edit the issue we will also need the issue number. Luckily n8n has a Merge node which enables us to merge data from multiple nodes. When adding the merge node, we can choose how we want the merge to happen. Since our data source has no common fields we will use the append mode and 2 inputs. And we connect our AI and our Loop nodes as the inputs.

Now we successfully merged the data from GitHub and the data from AI and we are ready for the next step.

Next we need to access the data from both sources and we will do it by using the Code node. This is a very powerful node because we can write any custom logic we want. For demo purposes we will keep it simple and we will just extract and return the final data we need by adding this simple JavaScript code:

const data = $input.all();

const aiResponse = data[0].json.message.content;
const loopItemData = data[1].json;

return [{
  json: {
    issueNumber: loopItemData.number,
    type: aiResponse.type || "",
    priority: aiResponse.priority || "",
    complexity: aiResponse.complexity || "",
    summary: aiResponse.summary || ""
  }
}];

And the last step will be adding the GitHub node, but this time it will be Edit an issue node. And we can configure this node to use the issue number and labels we returned from previous node to update the item.

Final workflow looks like this:

Now we only need to trigger the flow and check the result on GitHub. It really did a good job and did the triage the same way I would do it myself. Of course in real world and with way too many issues we may need to tweak the prompt, but I am pretty confident that this would work very well in production settings as well.

Conclusion

I have to say, I am impressed by what n8n can do. Most of the heavy lifting is covered by built-in integrations with tools like GitHub, Slack, Jira, Google Drive, Notion, and more, making automation fast and simple. For anything the built-in nodes don’t cover, the Code block lets you write custom logic, call APIs directly, or manipulate data however you need.

The UI for building workflows is intuitive, so prototyping solutions is quick and straightforward. And if you don’t want to start from scratch, n8n offers pre-built workflow templates that can be just simply customized to your needs. You can even build your own custom nodes to extend n8n’s functionality beyond what’s available out of the box.

Some ideas of what can be automated:

Slack/Discord notification when a PR is created or merge
PR review notifications
Pulling data from multiple sources and creating reports
Pulling RSS feed and create a newsletter
Onboarding new employees - automatically create accounts and even assign first JIRA or GitHub tasks based on labels/priorities

In the end, there are no limits except your own imagination.

Coder Legion - Recent posts tagged n8n

How Much Does It Cost to Automate Lead Follow-Up in the Philippines?

Option A: Free DIY with Google tools

Option B: Cloud no-code tools

Option C: Self-hosted n8n on a VPS

Option D: Done for you

The cost at a glance

What I would recommend for a Philippine small business

Sources

I Solved the Same Gmail Problem Two Ways Without Noticing

Where logging was supposed to go

Gmail replaces your data

Noticing I'd solved it twice

Moving logging upstream

Checking real inboxes

A test case I wrote wrong

What this doesn't show

Ambiguous, Invalid, or System Error?

Three different reasons for not choosing a project category

invalid needed one more field

A model failure is not an invalid submission

Why I used explicit routing

What I can claim from these tests

How to Inspect an Agent Skill Before You Adopt It — with n8n and Agentel MCP

What the workflow does

What you'll need

1. Import the template

2. Create a read-only Reader credential

3. Check workflow settings before connecting

4. Connect the three MCP nodes

5. Check the connection

6. Inspect one Skill

7. Read the evidence, not just the green checkmark

Troubleshooting

Why use MCP for this?

Try it and tell us where it falls short

Escaping the Automation Tax: Migrating AI Agent Workflows to Self-Hosted n8n

1. The Bottleneck: Why Cloud Automation Fails AI Agents

2. The Architecture: Webhook-to-CRM Pipeline

3. The Code & Logic

Step 2: Payload Validation & Domain Sanitization (JavaScript)

Step 4: Prompt Structuring (Python)

4. Deployment & Performance: Handling the Chaos

5. Conclusion & Ready-to-use Workflow

🛠️ D'autres outils MR Studio qui pourraient vous intéresser :

How I Built a Multi-Agent Micro-SaaS Orchestration Engine in n8n (Zero Cloud Subscriptions)

1. The Bottleneck: Why Commercial Solutions are Overpriced or Fragile

2. The Architecture: Master/Worker Sub-Agent Farm

3. The Code & Logic: Handoffs and Sanitization

Domain Sanitization & Routing (JavaScript)

Context Structuring (Python)

LLM Prompt Structuring

4. Deployment & Performance

5. Conclusion & Ready-to-use Workflow

🛠️ D'autres outils MR Studio qui pourraient vous intéresser :

n8n Webhook Not Working? Test, Production, and 404 Fixes

Start with the symptom

Test URL versus Production URL

Use the Test URL while building

Use the Production URL after publishing

The n8n webhook 404 checklist

Check the HTTP method before the payload

Check the webhook path

Send a minimal request

Reverse proxy and public URL problems

What to log before handing the webhook into production

The production handoff

Each Fix to My Classification Prompt Exposed the Next Problem

Where it started

Problem 1: I'd defined the category by counting

Problem 2: the model had to commit before it could compare

Problem 3: the schema asked for the answer before the reasoning

Problem 4: the fix overcorrected

Cleaning up

Checking the boundaries

What this doesn't show

How I Built an OTel-Native GPU Profiler & LLM Gateway to Stop Bleeding Inference Costs

1. The Bottleneck: Why commercial solutions are overpriced or fragile

2. The Architecture: Step-by-step breakdown of how the pipeline works

3. The Code & Logic: Domain sanitization, LLM prompt structuring, and OTel Metrics

`invalid` needed one more field