DEV Community

Cover image for How I Built a Production-Grade Odoo 19 + n8n + WhatsApp + Groq AI Stack on $0 Infrastructure
Muhammad Gharis
Muhammad Gharis

Posted on

How I Built a Production-Grade Odoo 19 + n8n + WhatsApp + Groq AI Stack on $0 Infrastructure

#odoo #python #n8nbrightdatachallenge #docker

If you've ever tried to connect an ERP system to real-time messaging, AI processing, and workflow automation at the same time, you know how quickly the architecture can become messy.

If you've ever tried to connect an ERP system to real-time messaging, AI processing, and workflow automation at the same time, you know how quickly the architecture can become messy.

You need an ERP.

You need automation.

You need message intake.

You need AI processing.

You need validation.

You need logs.

You need deployment.

And very quickly, what started as “just connect WhatsApp to Odoo” becomes a full backend system.

I built omni-odoo-stack to explore that exact problem.

It is an open-source ERP automation stack built around:

  • Odoo 19 Community
  • PostgreSQL 16
  • n8n
  • FastAPI
  • Groq / Llama 3
  • WhatsApp Cloud API
  • Docker Compose
  • Nginx
  • Oracle OCI Always Free deployment path

The goal was simple:

Build a realistic ERP + automation + AI middleware architecture using open-source or free-tier-friendly tools.

Repository:

github.com/gharisj3/omni-odoo-stack

What the Stack Does

At a high level, the system connects five layers:

WhatsApp Cloud API
        ↓
n8n workflow orchestration
        ↓
FastAPI + Groq AI middleware
        ↓
Odoo 19 Community
        ↓
PostgreSQL 16
Enter fullscreen mode Exit fullscreen mode

When a WhatsApp message arrives, n8n receives the webhook, extracts the payload, sends the data to FastAPI for AI-assisted analysis, validates the structured response using Pydantic v2, and writes a clean CRM lead into Odoo.

The sender can then receive an automated WhatsApp confirmation.

The important part is not just that the flow works conceptually.

The important part is the separation of responsibilities.

Odoo remains the ERP core.

n8n handles workflow orchestration.

FastAPI acts as the AI safety boundary.

PostgreSQL stores the business data.

WhatsApp handles the communication layer.

Infrastructure Stack

Layer Tool Cost
ERP Odoo 19 Community $0
Database PostgreSQL 16 $0
Automation n8n self-hosted $0
AI middleware FastAPI $0
LLM provider Groq / Llama 3 Free-tier friendly
Messaging Meta WhatsApp Cloud API Free-tier friendly
Reverse proxy Nginx $0
Deployment Docker Compose $0
Hosting target Oracle OCI Always Free $0
SSL Let's Encrypt $0

Oracle OCI Always Free is useful for this kind of project because the ARM instance can provide enough resources for a small ERP automation stack without needing a paid VPS.

The repo is designed with OCI deployment in mind, but I am being careful with wording here:

This is a production-style portfolio architecture.

It is not yet being claimed as a fully production-deployed system until the full Docker runtime has been boot-tested on OCI.

That distinction matters.

The Four Custom Odoo Modules

I built four custom Odoo modules from scratch. Each module handles a different part of the system.

1. omni_crm

omni_crm extends crm.lead.

It adds:

  • Computed lead scoring
  • AI analysis fields
  • WhatsApp contact shortcut behavior
  • Public lead intake API
  • Demo CRM lead data

The key endpoint:

POST /api/omni/lead
Enter fullscreen mode Exit fullscreen mode

This endpoint allows external systems like n8n to create leads in Odoo through a clean REST-style controller instead of forcing all automation through manual imports or UI actions.

2. omni_whatsapp

omni_whatsapp introduces a new model:

omni.whatsapp.message
Enter fullscreen mode Exit fullscreen mode

It stores WhatsApp message activity inside Odoo.

Fields include:

  • Phone number
  • Message body
  • Direction: inbound or outbound
  • Status
  • Linked CRM lead
  • Message history

It also includes webhook endpoints for Meta WhatsApp Cloud API integration:

GET  /whatsapp/webhook
POST /whatsapp/webhook
Enter fullscreen mode Exit fullscreen mode

The GET endpoint is used for Meta webhook verification.

The POST endpoint receives inbound WhatsApp events.

3. omni_ai

omni_ai introduces:

omni.ai.request
Enter fullscreen mode Exit fullscreen mode

This module logs AI requests and responses.

It stores:

  • Prompt
  • Response
  • Model used
  • Token usage
  • Status
  • Timestamp

It also includes an hourly cron job to process unanalyzed leads.

The idea is simple:

Do not let AI calls disappear into the background.

Every AI action should be visible, inspectable, and traceable inside the ERP.

4. omni_automation

omni_automation introduces:

omni.automation.log
Enter fullscreen mode Exit fullscreen mode

This module tracks end-to-end automation events.

It can be used to monitor:

  • WhatsApp intake
  • CRM lead creation
  • AI processing
  • Vendor bill automation
  • HR onboarding automation
  • Failed workflow events

It includes tree, form, and graph views so the automation layer is visible inside Odoo.

That visibility is important.

Automation without logs becomes a black box.

Why the AI Middleware Lives Outside Odoo

This was the most important architectural decision in the project.

A lot of AI-connected ERP implementations put LLM calls directly inside ERP models or controllers.

That works for demos, but it creates problems later.

Problems include:

  • Prompts become tightly coupled to Odoo modules
  • Model changes require ERP code changes
  • Raw LLM responses can accidentally corrupt ERP records
  • Validation becomes inconsistent
  • Token usage is harder to track
  • Swapping models becomes harder than necessary

So I separated the AI layer into a standalone FastAPI service.

Odoo does not talk directly to the model.

n8n and Odoo communicate with the middleware.

The middleware validates input, calls the LLM, validates output, and only then returns structured data.

Example Pydantic v2 model:

from typing import Literal
from pydantic import BaseModel, Field


class LeadAnalysis(BaseModel):
    score: int = Field(ge=1, le=10)
    summary: str
    next_action: str
    priority: Literal["low", "medium", "high"]
Enter fullscreen mode Exit fullscreen mode

Example invoice extraction model:

from datetime import date
from pydantic import BaseModel


class LineItem(BaseModel):
    description: str
    quantity: float
    unit_price: float
    total: float


class InvoiceData(BaseModel):
    vendor: str
    amount: float
    date: date
    currency: str
    line_items: list[LineItem]
Enter fullscreen mode Exit fullscreen mode

Every AI response must match the expected schema before it reaches Odoo.

If the response is missing a field, has the wrong type, or produces an invalid value, the middleware returns an error and the workflow can log the failure.

Odoo never receives unsafe data.

That is the entire point of the middleware.

FastAPI Middleware Endpoints

The middleware exposes these endpoints:

GET  /health
POST /analyze/lead
POST /extract/invoice
POST /generate/message
Enter fullscreen mode Exit fullscreen mode

Example flow:

n8n receives WhatsApp webhook
        ↓
n8n sends payload to FastAPI
        ↓
FastAPI calls Groq / Llama 3
        ↓
Pydantic validates structured output
        ↓
n8n writes validated data into Odoo
Enter fullscreen mode Exit fullscreen mode

The middleware is also easier to evolve independently.

If I want to replace Groq with OpenAI, Claude, or another model provider, I can change the middleware layer without rewriting Odoo modules.

That is the benefit of keeping AI outside the ERP core.

The Three n8n Workflows

The repo includes three importable n8n workflow JSON files.

Workflow 1: WhatsApp Lead Intake 

Meta WhatsApp webhook
        ↓
Extract contact and message data
        ↓
Call FastAPI /analyze/lead
        ↓
Validate AI response
        ↓
Create CRM lead in Odoo
        ↓
Send WhatsApp confirmation
        ↓
Log automation event
Enter fullscreen mode Exit fullscreen mode

This workflow is designed for businesses that receive leads through WhatsApp and want automatic CRM creation.

Workflow 2: Invoice Processing 

Invoice payload or WhatsApp invoice text
        ↓
Call FastAPI /extract/invoice
        ↓
Validate structured invoice data
        ↓
Create vendor bill in Odoo
        ↓
Send confirmation
        ↓
Log validation failures if needed
Enter fullscreen mode Exit fullscreen mode

This flow demonstrates how AI extraction can be placed behind validation before data enters accounting workflows.

Workflow 3: HR Onboarding 

Employee onboarding form
        ↓
Create employee in Odoo
        ↓
Generate welcome message through AI middleware
        ↓
Send WhatsApp notification to employee
        ↓
Notify HR manager
        ↓
Log onboarding event
Enter fullscreen mode Exit fullscreen mode

This workflow demonstrates how the same architecture can support HR automation, not just sales or finance.

Five Things I Learned While Building This

1. n8n's Odoo Node Is Not Enough for Every Case

The built-in Odoo node in n8n is useful, but custom Odoo REST controllers often require HTTP Request nodes.

For custom endpoints, the practical pattern is:

Authenticate with Odoo
Store session/cookie
Call custom REST endpoint
Handle response
Log errors
Enter fullscreen mode Exit fullscreen mode

For complex projects, I prefer explicit HTTP Request nodes because they make the flow easier to debug.

2. WhatsApp Webhook Idempotency Matters

Messaging systems can resend webhook events.

If your workflow creates a CRM lead every time it receives the same message, you can end up with duplicate leads.

The fix is to store and check a unique message identifier before creating records.

In real projects, I would always design the WhatsApp intake layer with duplicate prevention.

3. Pydantic v2 Requires Correct Syntax

Pydantic v2 introduced changes from v1.

If you are using it for AI output validation, make sure your models and validators follow v2 syntax.

The goal is not just to parse JSON.

The goal is to reject unsafe or malformed output before it touches business systems.

4. Odoo Filestore Persistence Is Easy to Miss

Odoo stores attachments in the filestore.

If the filestore is not mounted properly in Docker, attachments can disappear when containers are recreated.

For an ERP system, that is not acceptable.

Docker volumes need to be planned carefully.

5. Docker Services Should Talk by Service Name

Inside a Docker Compose network, services should not call each other using localhost.

Example:

Wrong:
http://localhost:8069

Correct:
http://odoo:8069
http://ai-middleware:8000
http://n8n:5678
Enter fullscreen mode Exit fullscreen mode

This sounds basic, but it is one of the most common causes of connection errors when wiring multiple services together.

Nginx Routing

The stack uses Nginx as the reverse proxy.

The intended routing is:

/       → Odoo
/n8n/   → n8n
/ai/    → FastAPI middleware
Enter fullscreen mode Exit fullscreen mode

Example configuration pattern:

location / {
    proxy_pass http://odoo:8069;
}

location /n8n/ {
    proxy_pass http://n8n:5678/;
    rewrite ^/n8n/(.*)$ /$1 break;
}

location /ai/ {
    proxy_pass http://ai-middleware:8000/;
    rewrite ^/ai/(.*)$ /$1 break;
}
Enter fullscreen mode Exit fullscreen mode

The rewrite rules matter because services like n8n and FastAPI may not expect the external prefix in the request path.

About Groq and Rate Limits

The project is designed to work with Groq and Llama 3-style structured AI tasks.

For real deployments, rate limits should always be checked from the current provider dashboard because limits can change.

In production-style workflows, I would add:

  • Wait nodes in n8n
  • Retry logic
  • Backoff handling
  • Token usage logging
  • Fallback behavior
  • Dead-letter logging for failed events

The goal is not just to call an AI model.

The goal is to make the AI call reliable enough for business workflows.

Repository Contents

The repository includes:

  • Docker Compose setup
  • Odoo configuration
  • Nginx configuration
  • Four custom Odoo modules
  • FastAPI AI middleware
  • Three importable n8n workflows
  • Environment example file
  • README
  • Setup documentation
  • Architecture notes
  • Phase notes

Repository:

github.com/gharisj3/omni-odoo-stack

What I Would Do Differently

One thing I would change is boot-testing the full Docker stack before publishing the first public version.

The project has been scaffolded, committed, documented, and syntax-checked.

Python syntax, JSON workflow files, and XML structure were reviewed.

But full runtime verification on OCI is still pending.

That is why I describe this as a production-style architecture rather than claiming it is already production-deployed.

That wording matters.

If you deploy it and hit issues, open an issue on GitHub. I am happy to improve the repo based on real runtime feedback.

Who This Is For

This project is useful for:

  • Odoo developers learning external automation patterns
  • n8n users integrating workflows with Odoo
  • Backend engineers exploring ERP automation
  • Odoo partners evaluating AI middleware architecture
  • Agencies that need WhatsApp + ERP workflow examples
  • Developers looking for a free-tier-friendly ERP automation stack

Why This Matters

Most ERP automation problems are not just workflow problems.

They are backend reliability problems.

You need:

  • Clean data models
  • Safe API boundaries
  • Structured validation
  • Retry handling
  • Duplicate prevention
  • Event logs
  • Database persistence
  • Deployment clarity

That is what this project is meant to demonstrate.

Not just that Odoo can connect to AI.

But that AI, automation, messaging, and ERP can be designed as separate layers that work together cleanly.

About Me

I am a backend engineer specializing in:

  • Odoo ERP customization
  • Python backend systems
  • n8n workflow automation
  • PostgreSQL optimization
  • WhatsApp Cloud API integration
  • Claude/OpenAI/Groq AI middleware
  • Pydantic-validated structured outputs

I have 8+ years of production experience across Odoo v14–v19 and backend automation work.

I am open to remote contract work with Odoo partners, SaaS teams, and agencies.

GitHub:

github.com/gharisj3

LinkedIn:

linkedin.com/in/muhammad-gharis-javed-318266202

Project repo:

github.com/gharisj3/omni-odoo-stack

Top comments (0)