Evolution API: self-hosted WhatsApp for Argentine startups (2026 guide)

Evolution API is a self-hosted gateway that lets you connect WhatsApp to your stack without paying for the official Cloud API. In LATAM 2026 it's the most used option for chatbot MVPs, with infra cost of USD 10-20/month and 30-minute deploy on Hostinger VPS with Docker Compose.

TL;DR

• Evolution API = open-source wrapper over Baileys that exposes WhatsApp Web as a REST API + webhooks.
• Deployed via Docker Compose on any VPS (Hostinger KVM 2 is enough, USD 7-15/month).
• Native integration with n8n, Chatwoot, Typebot and any stack that consumes webhooks.
• Real risk: number ban. With proper warm-up the risk drops, but it does not go away.
• For critical production or volumes >1000 conversations/month, migrate to Meta's official Cloud API.

What Evolution API is and why it's so widely used in LATAM

Evolution API is an open-source project (Apache 2.0 license) that exposes the Baileys protocol — an unofficial WhatsApp Web client implementation — as a REST API with webhooks. In practice, it means you can send and receive WhatsApp messages from any system without a contract with Meta.

The reason it dominates in LATAM and LatAm is simple: the official Cloud API charges per conversation in USD and requires a number verified in Business Manager. For an SMB just starting with a chatbot, that's friction and cost. Evolution API lowers the barrier to a USD 10/month VPS and any phone number.

Minimum architecture

1. Evolution API container (Node.js + TypeScript) — exposes REST endpoints and handles WhatsApp Web sessions via Baileys.
2. PostgreSQL — stores instances, contacts, messages, chats.
3. Redis (optional but recommended) — session cache and message queue.
4. External webhook — Evolution sends every incoming message to the URL you define (typically n8n or your backend).

When a customer sends a WhatsApp to your number, the flow is: WhatsApp Web → Evolution API → webhook POST → your processing (n8n, Python, Node) → response via Evolution → customer's WhatsApp.

Evolution API vs Meta's official Cloud API

Key differences you need to be clear on before deciding.

Evolution API (self-hosted, unofficial)

• Cost: only VPS, USD 10-20/month.
• Volume: technically unlimited, limited by ban risk.
• Number: any cellphone, no Business Manager verification required.
• Templates: not applicable, you send any text.
• Advantages: fast, cheap, flexible, multi-instance.
• Disadvantages: violates WhatsApp ToS, ban risk, no official SLA.

Official Cloud API (WhatsApp Business Platform)

• Cost: USD 0.005-0.08 per conversation depending on category (utility, marketing, authentication, service).
• Volume: unlimited and no ban risk.
• Number: mandatory verification in Business Manager, approved display name.
• Templates: mandatory to start conversations outside the 24h window.
• Advantages: official, stable, native interactive buttons, enterprise compliance.
• Disadvantages: approval bureaucracy, variable cost, slow iteration.

At StriqTech we recommend Evolution API for MVP and Cloud API for critical production. It's the same logic any startup uses: validate fast and cheap, then scale on official infrastructure.

Step-by-step Evolution API setup on Hostinger with Docker Compose

This is the complete recipe we use to deploy Evolution API for StriqTech clients. Assumes Hostinger VPS with Easypanel or Docker Swarm installed.

Step 1: base docker-compose.yml

Create a docker-compose.yml file with these services:

1. evolution-api — image atendai/evolution-api:v2.2.3 (or the latest stable as of 2026).
2. postgres — image postgres:16-alpine, persistent volume.
3. redis — image redis:7-alpine, persistent volume.

Expose port 8080 behind a reverse proxy (Traefik or nginx) with a Let's Encrypt certificate.

Step 2: critical environment variables

The ones you can't skip:

• AUTHENTICATION_API_KEY — master key to call the API (generate one with openssl rand -hex 32).
• DATABASE_PROVIDER=postgresql and DATABASE_CONNECTION_URI=postgresql://user:pass@postgres:5432/evolution.
• CACHE_REDIS_ENABLED=true + CACHE_REDIS_URI=redis://redis:6379.
• WEBHOOK_GLOBAL_URL — URL of your n8n (http://n8n:5678/webhook/evolution).
• WEBHOOK_GLOBAL_ENABLED=true.
• CONFIG_SESSION_PHONE_CLIENT=EvolutionAPI and CONFIG_SESSION_PHONE_NAME=Chrome (reduces detection flags).

Step 3: create the first instance

With the API up, POST to /instance/create with JSON body:

{
  "instanceName": "ventas",
  "qrcode": true,
  "integration": "WHATSAPP-BAILEYS"
}

The response includes the QR in base64. Open WhatsApp on your phone → Linked devices → scan it.

Step 4: verify the webhook

Send a test message to the number. In the Evolution logs you'll see the POST to the global webhook. If you use n8n, set up a Webhook node with path /evolution and you'll already have the message as parseable JSON.

Step 5: reverse proxy and domain

Point a subdomain (e.g. wa.yourdomain.com) to the VPS, configure Traefik or nginx to proxy port 8080 with HTTPS. Never expose Evolution API over plain HTTP: tokens travel in headers.

Integration with n8n and Chatwoot

The real production stack we implement at StriqTech is Evolution API + n8n + Chatwoot + PostgreSQL. Each piece does something concrete.

Evolution API + n8n

In n8n you create a Webhook node that receives each message from Evolution. There you build the flow:

1. Parse the payload (fields data.key.remoteJid, data.message.conversation, data.pushName).
2. Save the message in PostgreSQL for analytics.
3. Classify the intent with OpenAI or Claude (HTTP Request node with GPT-5 or Claude API).
4. Query your CRM (HubSpot, Tokko, whatever you use) via API.
5. Send the response via HTTP Request to POST /message/sendText/{instance} of Evolution.

Important: never use fetch() inside n8n Code nodes, always use HTTP Request nodes. It's an internal StriqTech convention and avoids timeout issues.

Evolution API + Chatwoot

Chatwoot is the multi-agent support dashboard. The integration is native from Evolution v2: in the instance you configure the fields chatwoot_account_id, chatwoot_token, chatwoot_url. Every WhatsApp conversation shows up as an inbox in Chatwoot, human agents reply from there, and the message goes out through Evolution.

The combo n8n (for automated logic) + Chatwoot (for humans when the bot doesn't know) is the pattern we use most in WhatsApp projects.

Ban risks and how to mitigate them

This is the point that will matter most if you go to production. Meta bans numbers it detects as automated. The detection uses signals like: outgoing message volume, time patterns, repetitive content, outgoing/incoming ratio, spam reports.

Proven mitigations

1. Progressive warm-up. Day 1: 50 outgoing messages. Day 7: 200. Day 14: 500. Day 30: whatever you need. Never start with high volume.
2. Real conversations, not broadcasts. If you only reply to whoever writes to you first, the risk drops to a minimum. Broadcasting to contacts without opt-in is what triggers bans.
3. Natural language, not repetitive templates. Vary greetings, personalize with the name, use moderate emojis.
4. Respect business hours. No replying at 3am at scale. Configure windows 9am-9pm AR in n8n.
5. Dedicated number. Never use the owner's personal number or the company's main one. A separate SIM is USD 5.
6. Health monitoring. Evolution exposes the /instance/fetchInstances endpoint with status. If it switches to close repeatedly, session issue.

With that setup the risk drops, but it does not go away: if the number is critical to your operation, that risk is the argument for moving to Cloud API.

Real costs in 2026: Evolution API vs Cloud API

Concrete numbers for you to compare.

Scenario A: SMB with 300 conversations/month

• Evolution API on Hostinger KVM 2: USD 7.99/month + 1 active instance. Total: USD 8/month.
• Official Cloud API: 300 service category conversations at USD 0.0147 each (AR 2026 rate): USD 4.4/month + integration development cost.

At low volume, Cloud API is cheaper on infra but charges per conversation and demands bureaucracy.

Scenario B: e-commerce with 5000 conversations/month

• Evolution API on Hostinger KVM 4: USD 15/month. Total: USD 15/month.
• Official Cloud API: 5000 conversations mix service+utility at an average USD 0.02: USD 100/month.

At high volume, Evolution API is 6-7x cheaper but you take the ban risk.

Scenario C: agency with 10 clients and 10 instances

• Evolution API on Hostinger KVM 4: USD 15/month, 10 instances in the same container.
• Cloud API: 10 verified numbers × cost per client, bureaucracy x10.

For agencies and multi-client operations, Evolution API is the option we usually recommend, as long as the ban risk is accepted.

5 use cases where Evolution API is justified

1. Chatbot MVP to validate before investing in Cloud API.
2. Marketing agency with many small clients where Cloud API is overhead.
3. Internal company support (sales team, support) where the number is dedicated.
4. Real estate and clinics with 100-500 conversations/month where the Cloud API cost doesn't pay back the verification effort.
5. Collections automation with messages to contacts who already owe you (established commercial relationship, low spam report risk).

If your case doesn't fit any of those, start directly with Cloud API.

When to migrate to the official Cloud API

Clear signals that your Evolution API has completed its cycle:

• You sustainably exceed 1000 conversations/month.
• An enterprise client requires compliance and official SLA.
• You've already had 1 ban and don't want it again.
• You need interactive buttons, list messages, native Meta payments.
• Your business depends 100% on WhatsApp (if it goes down, the company goes down).

Migration is not trivial: you have to verify the number in Business Manager, approve display name, migrate templates, rewrite the sending layer in your backend. Budget 1-2 weeks of technical work.

How we implement it at StriqTech

Evolution API is almost never the project itself: it is the piece that connects WhatsApp to the rest of your systems (CRM, ERP, online store, order system). That is why we work in three steps:

1. Understand the need: a first conversation, with no commitment, about which process you want to solve and which systems it has to talk to.
2. Proposal: scope, deliverables, dependencies and acceptance criteria in writing. That is where we decide whether Evolution API or Cloud API makes more sense, and which maintenance, hosting or third-party services are included.
3. Build and go-live: we build it, test it with the people responsible on your team and agree on the go-live and maintenance.

Timelines are set in each proposal, separating our work from what depends on your team or on third parties, such as Meta's verification if the project goes through Cloud API.

Related internal links

• Pillar guide: WhatsApp automation in LATAM.
• Related cluster: how to measure the return on a WhatsApp chatbot.
• Services: automation and AI, including WhatsApp assistants.
• Direct technical contact: WhatsApp +54 9 11 5499-7296.

CTA

If you want Evolution API connected to your systems without fighting Docker, Baileys and manual warm-up, tell us what process you want to solve. Write to us at +54 9 11 5499-7296 or go to striqtech.com: after that first conversation we propose the next step, with scope, stages and timelines.