The Invoice Came In at 11pm. The Workflow Classified It, Flagged It, and Drafted the Rejection by 11:01.
The first time the AI invoice approval flow actually worked end-to-end, I did not feel the thing you are supposed to feel when a technical problem resolves. I felt suspicious. It had failed so many times in so many specific ways that a clean execution felt like the tool was hiding something from me. I opened the execution log and read through every node output top to bottom. HTTP Request to the Claude API, response parsed correctly, IF node routing to the right branch based on the classification, Set node building the rejection draft, final HTTP Request posting to Slack. All green. All correct. Eleven seconds from webhook trigger to Slack message.
I closed the laptop and went to make tea and thought about how I had spent the previous four days getting to that eleven seconds.
The Claude integration is not in the n8n node library as a first-class credential type, which means you are building it yourself with an HTTP Request node, which is fine, that is genuinely the right way to do it, but the documentation for the Anthropic Messages API has a detail that cost me about three hours on day two. The base URL in the n8n HTTP Request credential configuration needs to be set without a trailing slash. The Anthropic API endpoint is https://api.anthropic.com/v1/messages. If you set the base URL as https://api.anthropic.com/ and then put v1/messages in the path field, you get a 404 that looks, at first reading, like an authentication error because the response body comes back malformed in a way that makes the credential look wrong rather than the URL. I went through my API key twice, regenerated it once, checked the header configuration for the anthropic-version field, and was about thirty minutes into reading the n8n community forum before someone in a two-year-old thread mentioned the trailing slash problem in a comment that had four upvotes and no official acknowledgement.
That is a documentation failure. Not a catastrophic one, not the kind of thing that breaks a product, but the kind of gap that burns hours for people who are building real things on a deadline and cannot afford to rediscover solved problems from scratch.
The reason I am building these AI integrations inside n8n rather than through any of the purpose-built AI automation frameworks is something I want to explain carefully, because the honest answer is less flattering to the AI tooling ecosystem than most of the coverage suggests. LangChain is the obvious alternative when you start looking at agent-based AI workflows. The demos are genuinely impressive. The conceptual architecture is sound. Chains, agents, tools, memory, retrieval, it is all there and it is all documented extensively. What the documentation does not prepare you for is what happens when you take a LangChain agent that worked perfectly in a Jupyter notebook and try to run it as a production process that handles real data from real clients on a schedule. The error handling is inconsistent. The retry behaviour on API failures is not configurable in the ways you need it to be configurable. The logging, which matters enormously when a client asks you why a workflow processed a document incorrectly, gives you enough to debug a demo and not enough to diagnose a production incident. I have spent more time inside LangChain’s source code trying to understand why something failed than I have spent building the actual workflows, and I build things for clients who are paying for working software, not for my education in Python debugging.
n8n does not have LangChain’s conceptual sophistication. The AI Agent node and the LangChain integrations inside n8n are a layer on top of the underlying library, which means you are still dealing with some of its behaviour, but the execution is inside n8n’s runtime, which means you get n8n’s error handling, n8n’s retry logic, n8n’s execution logs, and n8n’s ability to pause a workflow mid-execution and inspect the state. That last one is something that sounds minor until you are trying to work out why an LLM classification sent three invoices to the wrong approval queue at two in the morning, at which point the ability to click on the IF node output and read the exact JSON that drove the routing decision is the difference between a fifteen-minute fix and a two-hour investigation.
ChatGPT plugins had a similar problem from a different angle. The plugin architecture was designed to extend what a user could do inside a conversation, which is a useful thing, but it had no answer to the question of what happens when the process needs to run without a human initiating it. An invoice arrives. A lead fills in a form. A sensor reading crosses a threshold. None of those events are user-initiated conversations. The plugin architecture had no runtime for unattended execution, no scheduling, no webhook intake, no branching logic for different data shapes. It was a UI extension pretending to be an automation platform.
What is actually useful about AI inside n8n is not the intelligence, it is the plumbing. The intelligence is the LLM doing classification or extraction or drafting. The plumbing is the Webhook node receiving the trigger, the HTTP Request node calling the API, the IF node routing on the result, the Set node formatting the output, the next HTTP Request posting it somewhere. That plumbing already existed, was already tested, already had error handling, already had retry logic. The AI is a node in a workflow that was already working. It did not replace the workflow architecture. It extended it.
The eleven seconds from webhook to Slack message is not impressive because of the AI. It is impressive because everything around the AI was already solid before I added it. Build the plumbing first. The intelligence only matters if the pipes don’t leak.
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.