No cenário de 2026, criar um bot de WhatsApp com IA que responde automaticamente a clientes tornou-se fundamental para muitas empresas que buscam aprimorar seu atendimento. Neste artigo, vou detalhar todo o processo que utilizei para desenvolvimento de um bot eficaz e suas respectivas implementações.
# Instalando dependências
pip install Flask requests pymongo
# Importando bibliotecas
from flask import Flask, request
from pymongo import MongoClient
import requests
app = Flask(__name__)Para o nosso bot, utilizamos o Flask para criar uma API que permite o recebimento de mensagens do WhatsApp e o envio de respostas.
# Configurando conexão ao MongoDB
client = MongoClient('mongodb://localhost:27017/')
db = client['whatsapp_bot']
@app.route('/webhook', methods=['POST'])
def webhook():
data = request.json
# Processando a mensagem recebida
message = data['messages'][0]['text']
user_id = data['messages'][0]['from']
# Enviar resposta usando Dialogflow
response = requests.post('DIALOGFLOW_ENDPOINT', json={'query': message})
response_text = response.json()['response']
# Salvar interações no MongoDB
db.messages.insert_one({'user_id': user_id, 'message': message})
return {'text': response_text}Após a implementação, chegou a hora de testar nosso bot. Para isso, podemos usar ferramentas como Postman ou cURL.
# Exemplo de chamada de teste usando cURL
curl -X POST https://seu_dominio/webhook \
-H 'Content-Type: application/json' \
-d '{"messages": [{"from":"123456789", "text":"Olá"}]}')Construir um bot de WhatsApp com IA que responde automaticamente não é uma tarefa trivial, mas com as ferramentas certas e um entendimento claro de como funcionam as APIs, é possível criar uma solução robusta. Lembre-se de um monitoramento constante e de ajustes dos feedbacks dos usuários para garantir uma experiência excelente.
Python é a linguagem mais recomendada pela sua simplicidade e vasta biblioteca para IA.
Sim, grupos de marketing podem usar bots para automatizar interações com clientes, mas devem respeitar leis de privacidade.
Sim, o uso da API do WhatsApp pode ter custos dependendo do volume de mensagens enviadas.
Os riscos incluem falhas na compreensão das mensagens dos usuários e a necessidade de supervisão para evitar respostas inadequadas.
Recomendo utilizar um ambiente de teste local ou uma conta de WhatsApp secundária para desenvolver e testar as funcionalidades do bot.
Abaixo esta uma base mais realista para organizar configuracao, cliente de API, execucao e teste local.
# config.py
from dataclasses import dataclass
import os
@dataclass(frozen=True)
class Settings:
api_url: str
timeout: int
dry_run: bool
def load_settings() -> Settings:
return Settings(
api_url=os.getenv("API_URL", "https://exemplo.com/api"),
timeout=int(os.getenv("API_TIMEOUT", "30")),
dry_run=os.getenv("DRY_RUN", "true").lower() == "true",
)
# client.py
from typing import Any
import requests
class AutomacaoError(RuntimeError):
pass
class AutomacaoClient:
def __init__(self, api_url: str, timeout: int = 30) -> None:
self.api_url = api_url.rstrip("/")
self.timeout = timeout
def buscar_dados(self) -> dict[str, Any]:
try:
response = requests.get(f"{self.api_url}/status", timeout=self.timeout)
response.raise_for_status()
except requests.RequestException as exc:
raise AutomacaoError(f"Falha ao buscar dados: {exc}") from exc
return response.json()
def executar_acao(self, payload: dict[str, Any], dry_run: bool = True) -> dict[str, Any]:
if dry_run:
return {"modo": "teste", "payload": payload}
try:
response = requests.post(f"{self.api_url}/executar", json=payload, timeout=self.timeout)
response.raise_for_status()
except requests.RequestException as exc:
raise AutomacaoError(f"Falha ao executar acao: {exc}") from exc
return response.json()
# main.py
from config import load_settings
from client import AutomacaoClient
def montar_payload() -> dict:
return {
"tema": "bot de WhatsApp com IA",
"origem": "blog-tecnologia",
"prioridade": "normal",
}
def main() -> None:
settings = load_settings()
client = AutomacaoClient(settings.api_url, settings.timeout)
status = client.buscar_dados()
print("Status da API:", status)
resultado = client.executar_acao(montar_payload(), dry_run=settings.dry_run)
print("Resultado:", resultado)
if __name__ == "__main__":
main()
python -m venv .venv
source .venv/bin/activate
pip install requests
export API_URL="https://exemplo.com/api"
export DRY_RUN="true"
python main.py
# docker-compose.yml
services:
app:
build: .
command: python main.py
environment:
API_URL: "https://exemplo.com/api"
API_TIMEOUT: "30"
DRY_RUN: "false"
restart: unless-stopped
volumes:
- ./logs:/app/logs
worker:
build: .
command: python worker.py
environment:
API_URL: "https://exemplo.com/api"
DRY_RUN: "false"
restart: unless-stopped
# test_client.py
from client import AutomacaoClient
class FakeResponse:
def __init__(self, payload):
self.payload = payload
def raise_for_status(self):
return None
def json(self):
return self.payload
def test_execucao_em_dry_run():
client = AutomacaoClient("https://exemplo.com/api")
payload = {"tema": "bot de WhatsApp com IA", "prioridade": "normal"}
resultado = client.executar_acao(payload, dry_run=True)
assert resultado["modo"] == "teste"
assert resultado["payload"]["tema"] == "bot de WhatsApp com IA"
# risk.py
from decimal import Decimal
import logging
logger = logging.getLogger(__name__)
class RiskManager:
def __init__(self, saldo_total: Decimal, reserva: Decimal = Decimal("0.30")) -> None:
self.saldo_total = saldo_total
self.reserva = reserva
@property
def saldo_protegido(self) -> Decimal:
return self.saldo_total * self.reserva
@property
def saldo_operacional(self) -> Decimal:
return self.saldo_total - self.saldo_protegido
def calcular_tamanho(self, risco_por_operacao: Decimal, stop_percentual: Decimal) -> Decimal:
if stop_percentual <= 0:
raise ValueError("stop_percentual precisa ser maior que zero")
valor_em_risco = self.saldo_operacional * risco_por_operacao
tamanho = valor_em_risco / stop_percentual
logger.info("Tamanho calculado: %s", tamanho)
return tamanho
def pode_abrir_nova_posicao(self, posicoes_abertas: int, limite: int) -> bool:
if posicoes_abertas >= limite:
logger.warning("Limite de posicoes atingido")
return False
if self.saldo_operacional <= 0:
logger.warning("Saldo operacional indisponivel")
return False
return True
Uma implementacao solida nao deve misturar interface, regra de negocio, integracao externa e logs no mesmo arquivo. O caminho mais seguro e separar o projeto em camadas pequenas: configuracao, cliente de API, servico principal, fila de execucao, persistencia e painel de acompanhamento.
Essa divisao facilita teste, manutencao e evolucao. Se uma API externa muda, voce altera o cliente. Se a regra de negocio muda, voce altera o servico. Se a interface muda, o nucleo continua funcionando.
A configuracao deve vir de variaveis de ambiente. Isso evita senhas no codigo, permite ambientes separados e deixa mais simples rodar o mesmo projeto em desenvolvimento, staging e producao.
A execucao deve sempre ter logs claros, tratamento de erro e modo de teste. Em automacoes reais, o modo de teste evita que uma rotina execute acoes definitivas antes de voce validar parametros, permissao e formato dos dados.
Logs nao servem apenas para erro. Eles mostram decisoes tomadas pelo sistema: quando a rotina iniciou, quais dados recebeu, quais filtros aplicou, qual acao ignorou e qual acao executou. Sem isso, qualquer automacao vira uma caixa preta dificil de confiar.
Projetos conectados a APIs precisam de limites. Use timeouts, retries com cuidado, validacao de payload, permissao minima e nunca exponha chaves em frontend, repositorio ou print de terminal.
Depois da primeira versao funcionando, eu separaria o projeto em tres ciclos. O primeiro ciclo cuida da confiabilidade: logs melhores, tratamento de erro, testes automatizados e ambiente de homologacao. O segundo ciclo cuida da experiencia: painel mais claro, filtros, historico de execucoes e mensagens de status compreensiveis. O terceiro ciclo cuida da escala: filas, workers, cache, monitoramento e deploy com rollback.
Essa ordem evita um erro comum em projetos de automacao: tentar escalar antes de entender se o fluxo e confiavel. Uma automacao pequena, mas bem observavel, e melhor do que um sistema grande que executa acoes sem explicar por que tomou cada decisao.
Antes de colocar qualquer rotina em producao, eu validaria entradas, saidas e limites. Isso inclui testar payloads vazios, respostas lentas, indisponibilidade da API, credenciais invalidas e cenarios de execucao duplicada. Tambem manteria um modo dry-run para simular a rotina sem executar a acao final.
Em projetos financeiros, operacionais ou integrados a contas reais, essa validacao e ainda mais importante. O sistema precisa falhar de forma segura, registrar o motivo da falha e nunca tomar uma acao irreversivel sem parametros bem definidos.
Quando o projeto sai do exemplo e entra em uso real, a parte mais importante nao e apenas fazer a automacao funcionar uma vez. O mais importante e garantir que ela consiga funcionar varias vezes, em dias diferentes, com dados diferentes e com falhas externas acontecendo. Por isso eu costumo pensar em idempotencia, auditoria e recuperacao desde o inicio.
Idempotencia significa evitar que a mesma acao seja executada duas vezes por acidente. Em uma integracao com API, por exemplo, voce pode registrar um identificador unico para cada execucao e consultar esse identificador antes de repetir a acao. Isso reduz risco quando existe timeout, queda de rede ou reinicio do servidor.
Auditoria significa deixar rastros claros. Cada execucao relevante deve registrar horario, entrada recebida, decisao tomada, resultado e eventual erro. Isso ajuda na manutencao e tambem cria confianca para o usuario final, porque o sistema consegue explicar o que aconteceu.
Recuperacao significa projetar o fluxo para voltar a operar depois de uma falha. Se uma chamada externa falha, o sistema precisa saber se deve tentar novamente, ignorar, pausar ou pedir revisao manual. Essa decisao nao deve ficar escondida em um bloco generico de excecao.
Outro ponto essencial e separar o que e regra de negocio do que e detalhe de infraestrutura. O codigo que calcula uma decisao nao deveria depender diretamente de Flask, Django, WordPress, Binance ou qualquer biblioteca especifica. Quanto mais isolada a regra, mais facil testar, reutilizar e migrar.
Por fim, eu manteria um painel simples para acompanhar status. Mesmo que a automacao rode em terminal ou worker, um painel com ultimas execucoes, erros recentes, tempo medio, modo atual e botoes de pausa ajuda muito. Em automacoes que mexem com dinheiro, publicacao, vendas ou atendimento, visibilidade vale tanto quanto velocidade.
Tambem vale criar um roteiro de revisao antes de cada deploy. Eu verificaria se as variaveis de ambiente estao presentes, se o modo de teste esta funcionando, se os logs estao sendo gravados, se os limites de seguranca continuam ativos e se existe um caminho claro para pausar a automacao. Esse tipo de checklist parece simples, mas evita muitos problemas quando o sistema passa a rodar todos os dias.
Em resumo, a implementacao tecnica precisa equilibrar tres coisas: capacidade de executar, capacidade de explicar e capacidade de parar. Um sistema que executa mas nao explica vira risco. Um sistema que explica mas nao tem botao de parada tambem vira risco. O ideal e construir a automacao com controles desde o primeiro prototipo.
Esse cuidado muda tudo.
Eu tambem preparei uma aula em video sobre este tema, com explicacao visual e passo a passo.
Abrir video no YouTube: Bot de WhatsApp com IA em Python: webhook funcionando do zero