AI Workflows with n8n: From Idea to Production Automation

Chat interfaces like Open WebUI solve "human asks, AI answers." In practice, the second half is almost always missing: What happens with the answer? Update the ticket system, notify Slack, create a CRM entry, escalate on urgency. For that I use n8n — self-hosted, visual, with hundreds of integrations.

I came to n8n from systems administration. As a sysadmin I spent years wiring cron jobs and scripts. n8n is the modern version: triggers, steps, error paths — visible in the editor, auditable, without building a separate microservice for every process. For AI projects, LLM calls are one step in the workflow, not the entire product.

This tutorial shows two workflows I need in almost every AI project: summary via webhook and a simple RAG pipeline. LLM requests go through LiteLLM; for manual testing and exploration I use Open WebUI in parallel.

n8n doesn't replace custom backend development when complex business logic, strict SLAs, or fine-grained permissions are required. But for 80% of "AI should then do X" requirements it's the fastest path — and ops teams understand visual workflows better than Python repos.

Who Is This For?

n8n pays off when AI should be embedded in existing processes — not isolated in a chat window. Typical cases:

• Ticketing: classify, summarize, prioritize incoming requests
• Document workflows: upload triggers embedding and indexing
• Notifications: LLM scores urgency → Slack/Teams/email
• Scheduled jobs: daily reports, knowledge updates, data quality checks

n8n is a poor replacement for a high-load API with strict sub-200 ms latency SLAs. For interactive human chat, Open WebUI remains the better choice. n8n is the glue between AI and enterprise systems.

Architecture at a Glance

Trigger (Webhook, Cron, Jira, Email)
              │
              ▼
            n8n Workflow
    (Transform, IF, Error Handler)
              │
    ┌─────────┼─────────┬──────────┐
    ▼         ▼         ▼          ▼
 LiteLLM   Vector DB   Jira     Slack
 (LLM)     (RAG)      (Ticket)  (Alert)

n8n orchestrates; it doesn't run inference itself. All LLM calls go to LiteLLM or another OpenAI-compatible endpoint.

Step 1: Start n8n Self-Hosted

services:
  n8n:
    image: n8nio/n8n:latest
    ports:
      - "5678:5678"
    environment:
      - N8N_HOST=n8n.internal.example.com
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.internal.example.com/
      - GENERIC_TIMEZONE=Europe/Berlin
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
    volumes:
      - n8n_data:/home/node/.n8n
    restart: unless-stopped

volumes:
  n8n_data:

WEBHOOK_URL must be the public or internal URL where webhooks are reachable — otherwise n8n generates wrong callback URLs. N8N_ENCRYPTION_KEY secures credentials in the database. Production: HTTPS, enable auth, backup the n8n_data volume.

I run n8n in the same Docker network as LiteLLM (ai-internal) so HTTP requests to http://litellm:4000/v1 run internally without TLS termination. Outward-facing is only n8n via reverse proxy — not LiteLLM directly.

Step 2: Workflow — LLM Summary via Webhook

Goal: POST with text → structured summary as JSON.

1. Webhook node: POST, path /summarize, optional authentication (header secret)
2. Set node: extract text from $json.body.text
3. HTTP Request → LiteLLM:

{
  "model": "companygpt-fast",
  "messages": [
    {
      "role": "system",
      "content": "Summarize the text in exactly 3 bullet points. Respond as JSON with a bullets array field."
    },
    {
      "role": "user",
      "content": "={{ $json.text }}"
    }
  ],
  "response_format": { "type": "json_object" }
}

4. Code node: parse JSON from choices[0].message.content
5. Respond to Webhook: return result

Store the API key as an n8n credential (header Authorization: Bearer …), never hardcode in the workflow. Set timeout to 60–120 seconds — LLMs are slow; that's normal.

Step 3: Workflow — Simple RAG Pipeline

Goal: question + context ID → answer with sources.

Webhook → Embedding (HTTP) → Vector DB query → Build context
       → LLM chat → Return answer + chunk IDs

Embedding step (HTTP request to LiteLLM/OpenAI):

{
  "model": "text-embedding-3-small",
  "input": "={{ $json.question }}"
}

Vector search: Qdrant, Weaviate, or pgvector via HTTP node, depending on stack. Merge top-5 chunks as context (code node or set with expression).

LLM step with a clear system prompt:

Answer only based on the following context.
If the answer is not in the context, say: "I don't have information on that."
Cite chunk IDs at the end of the answer.

This is a simplified pipeline — production criteria are in my RAG checklist: hybrid search, ACL, evaluation.

Step 3b: Workflow 3 — Ticket Classification with Jira

A pattern I build often: Jira trigger on new ticket → ticket description to LiteLLM → category and urgency as JSON → IF node → on urgency, Slack; otherwise just set label.

The system prompt is short and structured:

Classify the ticket. Respond as JSON:
{ "category": "outage|request|billing", "urgency": 1-10, "summary": "..." }

Important: validate JSON schema in the code node, fallback on parse errors. LLMs occasionally wrap JSON in markdown — the workflow breaks without validation.

Step 3c: Idempotency and Rate Limits

If the same webhook fires twice (caller retry), the same ticket must not be created twice. I store a hash ID of the input in a small table or check whether the operation already exists in the target system. I also limit concurrent LLM calls — n8n can otherwise empty the LiteLLM budget in minutes during a burst.

Step 4: Add Error Handling

Production workflows need visible error paths:

• Enable global Error Workflow (Settings → Workflow Settings)
• Retry on HTTP nodes: 3 attempts, exponential backoff
• IF node: catch empty embedding response or HTTP status ≠ 200
• Slack/Email node in error workflow for notification

A workflow that dies silently on LLM timeout is worse than one that returns an error. Users and ops need to know what happened.

Step 5: Scheduling, Sub-Workflows, and Monitoring

• Cron trigger: e.g. daily 7 AM summarize new Jira tickets
• Execute Workflow: shared LLM logic as sub-workflow, callable from multiple flows
• n8n logs + external (Grafana Loki, ELK) for production
• Limit execution data retention — LLM workflows often store large payloads

For LLM-heavy flows I export metrics: execution count, error rate, average latency per workflow. When the summary webhook suddenly jumps from 8 to 45 seconds, it's usually LiteLLM, the model, or the network — not "n8n is slow." Without that separation you debug the wrong layer.

Step 6: Versioning and Changes

n8n workflows live in the database, not necessarily in git. I export production flows regularly as JSON to the repo and document changes in the ticket system. A system prompt changed in the UI without review is a silent production deploy. AI workflows deserve the same discipline as code.

From the Field

An IT service provider (anonymized) received 150+ support emails daily. Goal: categorize (outage, request, billing), short summary, urgency score. n8n workflow: IMAP trigger → LLM classification via LiteLLM → on score > 8, Slack on-call + Jira ticket with summary.

First version without error handling: 12% of emails stuck because the model returned invalid JSON on empty subjects. Fix: schema validation in code node, fallback category "Unclear", alert to ops. After four weeks: 94% correct categorization, ~8 seconds per email. No replacement for human handling — but urgent cases rose to the top.

What Often Goes Wrong

API keys in the workflow. Visible in git, not rotatable. Use credentials.

No timeout. HTTP node waits forever; webhook caller gives up.

PII in execution logs. n8n stores input/output — minimize or anonymize personal data.

RAG without source checks. LLM hallucinates despite context. Chunk IDs and "no information" are mandatory.

Public n8n without auth. Webhooks are URLs. Anyone with the URL can burn your LLM budget.

Go-Live Checklist

1. n8n with HTTPS and N8N_ENCRYPTION_KEY
2. LiteLLM credentials as n8n credential, virtual key with budget
3. At least one workflow with error workflow and notification
4. Webhook secrets or IP restriction
5. Timeouts and retries on all HTTP nodes
6. No PII in persistent logs without a concept
7. Monitoring: alert on failed executions
8. Ops documentation: what to do on LiteLLM outage

Conclusion

n8n is the glue between AI and existing systems. Where Open WebUI serves humans, n8n automates recurring AI tasks — with visible error paths and an audit trail. Together with LiteLLM for model governance and a solid RAG pipeline for knowledge questions, the picture fits together.

Workflow design for your integration? LinkedIn