The morning SAP announced the acquisition I was three hours into debugging a webhook that was returning 200 but not actually firing. Classic. The workflow looked fine in the canvas, the test execution showed green, and the production instance was doing absolutely nothing. Turned out the webhook URL in the production environment was still pointing at the tunnel I had used during local development two weeks earlier, and nobody, including n8n, had flagged it. I found out because a client messaged asking why their CRM had not updated since Tuesday. That is the context in which I read the news. Five point two billion dollars. SAP. n8n.
I had to read it twice.
Not because it surprised me that someone would pay serious money for n8n. I have been building on it long enough to know what it can actually do when you stop treating it like a prettier Zapier and start treating it like the workflow engine it actually is. What surprised me was the number. SAP does not spend five billion dollars on bets. SAP spends five billion dollars on certainties that have already been proven in enterprise environments it controls, and the fact that n8n qualified for that category tells you something about how far the tool has travelled from the self-hosted Docker experiment most people still think it is.
Let me tell you what n8n actually is, because the coverage I have read since the announcement has mostly been written by people who have never opened the canvas. It is a workflow automation platform that runs on your infrastructure, gives you access to every node as code if you need it, and does not charge you per task in a way that punishes you for building automations that actually do things. That last part matters more than it sounds. I moved a client off Zapier last year because their monthly bill had reached a point where the automation was costing more than the time it was saving. The workflow was not complicated. It was just running frequently, and Zapier’s pricing model treats frequency as a revenue opportunity. I rebuilt the whole thing in n8n in an afternoon, self-hosted it on a t3.small on EC2, and the client’s automation cost dropped to the price of the instance.
The migration from their existing Make.com flows was where things got interesting. Make has a better interface than n8n, I will say that directly, the visual logic is cleaner and the module library has a polish that n8n’s nodes do not always match. But Make starts to show its limits when your workflow needs to do something the module did not anticipate. I hit this on a flow that needed to parse a nested JSON response from a third-party API and route differently based on values four levels deep. In Make, I was writing formulas in their expression syntax that looked like someone had dropped a keyboard. In n8n, I dropped a Code node, wrote twelve lines of JavaScript, and it was done. That is the actual difference. Make is better when your problem fits the module. n8n is better when your problem does not.
The AI integration side is where I have spent most of my time in the last eighteen months. I built an invoice approval flow for a small finance team that used OpenAI function calling to extract line items, categorise spend, and flag anomalies before a human reviewed anything. The n8n side of it was an HTTP Request node hitting the OpenAI endpoint directly, a Code node parsing the function call response, and a set of IF nodes routing based on the extracted values. Straightforward in principle. In practice I spent three hours on a credential error that turned out to be a trailing slash in the base URL field that the OpenAI node was appending to. The error message said authentication failed. It was not authentication. It never is.
The documentation for the OpenAI node at the time was accurate for the version of the API that existed six months before I was using it. This is not unique to n8n. Every tool in this space has documentation lag because the APIs they connect to change faster than technical writers can track. But it is worth knowing that when something breaks on an AI node in n8n, the first thing to do is ignore the documentation entirely and read the raw request and response in the execution log. The log tells you what actually happened. The docs tell you what was supposed to happen.
On the SAP acquisition specifically, I think the people writing about it as a validation of no-code automation are missing what SAP actually bought. They did not buy a no-code tool. They bought a workflow engine that enterprise developers can extend, self-host, control, and audit in ways that Zapier and Make fundamentally cannot offer because their architecture does not allow it. SAP’s customers are not choosing between n8n and Zapier. They are choosing between n8n and building something internal from scratch, and five billion dollars says SAP thinks that comparison now favours n8n.
They are probably right. Which is a strange sentence to type while you are still manually checking webhook URLs.
The honest takeaway is this: n8n was already the correct choice for anyone building automations that need to last, scale, or touch data they cannot send to a third-party server. The SAP money does not change what the tool does. It just means the tool is going to be around long enough for the workflows you build on it today to still be running in five years, which is a thing you genuinely cannot assume about most of the platforms in this space.
That matters more than the headline number.
Olaitan Oladipo holds a BSc in Sociology from Olabisi Onabanjo University. He is a self-taught automation builder who has spent years inside n8n doing the work that most tutorials skip: debugging OAuth errors at 2am, migrating client automations from Make.com mid-project, fighting reverse proxy misconfigurations on AWS EC2, and figuring out through trial and error what actually holds up in production versus what only looks clean in a demo.
He is not a developer by training and not a SaaS founder. He is the person in the Discord server who actually answers the question instead of linking to the docs.
His writing on n8n Automation Tutorial covers self-hosting, AI agent workflows, tool comparisons, and the security vulnerabilities the automation industry would rather not discuss. He has built AI-assisted invoice approval flows using OpenAI function calling, connected Claude via HTTP Request nodes, and holds considered opinions about Zapier, Make.com, LangChain, and CrewAI that their marketing teams would not appreciate.
He writes for people who are technical enough to follow a tutorial but experienced enough to want the honest version.