MongoDB próprio na API do WhatsApp: seus dados de sessão e mensagens no seu banco

Na API não oficial da WAME você conecta o seu próprio MongoDB a uma instância com um único POST /instance/mongodb, informando a URI de conexão e o nome do banco — e a instância passa a guardar sessão e mensagens no seu banco, não num armazenamento que você não controla. É o recurso para quem precisa responder a perguntas como "onde ficam os dados dos meus clientes?", "por quanto tempo?" e "quem tem acesso?" com uma resposta que cabe num contrato.

A maioria das integrações nunca precisa disso: o armazenamento padrão é gerenciado e funciona. Mas para software houses, operações com exigência de compliance e times que querem analisar as conversas direto no banco, ter os dados em casa muda o jogo.

A camada não oficial não é afiliada, endossada ou suportada pelo WhatsApp ou pela Meta. O uso é de responsabilidade de quem envia.

Por que ter os dados no seu banco

Propriedade e localização. O banco é seu: você escolhe a região, o provedor e o plano. Se o seu cliente exige que os dados fiquem num ambiente específico, a resposta está pronta.

Retenção sob seu controle. Você define por quanto tempo as mensagens ficam guardadas e implementa a limpeza. Isso é central na LGPD: guardar só pelo tempo necessário para a finalidade.

Backup no seu ritmo. Snapshots, réplicas, restauração pontual — as ferramentas do seu MongoDB valem para os dados do WhatsApp também.

Análise direta. Relatórios, painéis e consultas de BI rodam contra o banco, sem paginar a API. Útil para métricas de atendimento, para treinar uma base de conhecimento de IA ou para auditoria.

Portabilidade. Se um dia você mudar a arquitetura, os dados já estão com você.

Como conectar

Primeiro, prepare o banco. No MongoDB Atlas (ou no seu cluster):

1. Crie um banco dedicado à instância — por exemplo, wame_loja_centro.
2. Crie um usuário exclusivo com permissão de leitura e escrita só nesse banco.
3. Libere o acesso de rede conforme a orientação da documentação.
4. Copie a URI de conexão (mongodb+srv://usuario:[email protected]).

Depois, conecte a instância:

curl -X POST "https://us.api-wa.me/SUA_KEY/instance/mongodb" \
  -H "Content-Type: application/json" \
  -d '{
    "uri": "mongodb+srv://wame_loja:[email protected]/?retryWrites=true&w=majority",
    "dbName": "wame_loja_centro"
  }'

A partir daí, o armazenamento de sessão e de mensagens da instância usa o seu banco. A estrutura das coleções é criada e mantida pela plataforma — explore pelo Compass ou pelo shell para ver o que é gravado, e trate essa estrutura como algo que a plataforma controla: leia à vontade, mas não altere documentos na mão.

Um banco por instância ou um para todas?

Para quem gerencia vários números — uma software house com dezenas de clientes, por exemplo — a pergunta aparece logo. A recomendação:

• Um banco (dbName) por instância, mesmo que no mesmo cluster. Isola os dados de cada cliente, facilita apagar tudo de um cliente que saiu e simplifica permissões.
• Um usuário por banco. Se uma URI vazar, o estrago fica restrito a um cliente.
• Cluster separado para clientes com exigência contratual específica.

O fluxo de criar, ativar, suspender e remover instâncias em escala está em provisionar WhatsApp para 100 clientes por API; o MongoDB entra como mais um passo nesse provisionamento.

Segurança: a URI é uma chave

A URI de conexão dá acesso à sessão e às mensagens da instância. Trate-a com o mesmo cuidado que a key da API:

• Guarde em cofre de segredos, nunca no código ou no repositório.
• TLS sempre. O Atlas já exige; num MongoDB próprio, configure.
• Menor privilégio. O usuário da instância não precisa de acesso administrativo ao cluster.
• Rede restrita. Libere só o necessário; nada de 0.0.0.0/0 sem senha forte e TLS.
• Auditoria e alertas de acesso no provedor do banco.
• Rotação de senha periódica — ao trocar, atualize a instância com um novo POST /instance/mongodb.

As outras frentes de segurança da integração (token, webhook, dados do cliente) estão em segurança da API do WhatsApp.

Retenção e LGPD na prática

Com os dados no seu banco, a política de retenção deixa de ser promessa e vira código. Um exemplo de desenho:

• Mensagens de atendimento: guardar por um prazo definido na sua política (o necessário para suporte e disputas) e apagar depois.
• Pedidos de exclusão: remover as mensagens daquele contato quando ele pedir.
• Mídia: os arquivos ficam no storage de mídia; para apagar todos os arquivos salvos da instância de uma vez, há um endpoint dedicado:

curl -X DELETE "https://us.api-wa.me/SUA_KEY/actions/storage"

A exclusão é permanente — use em rotinas de encerramento de contrato ou de limpeza planejada, nunca por impulso.

Se você revende a integração, documente no contrato onde os dados ficam e quem responde por eles. Os pontos que a sua software house precisa cobrir estão em API de WhatsApp e LGPD.

Analisando as conversas direto no banco

Com as mensagens no seu MongoDB, dá para responder perguntas de negócio com uma consulta. Como a estrutura exata das coleções é definida pela plataforma, comece inspecionando um documento real e adapte. Um esqueleto de agregação — contar mensagens recebidas por dia — ficaria assim:

// Exemplo ilustrativo: ajuste coleção e campos ao que você
// encontrar no seu banco (confira em /docs).
db.getCollection('SUA_COLECAO_DE_MENSAGENS').aggregate([
  { $match: { fromMe: false } },
  { $group: {
      _id: { $dateToString: { format: '%Y-%m-%d', date: '$createdAt' } },
      total: { $sum: 1 },
  } },
  { $sort: { _id: 1 } },
]);

Faça análises em réplica de leitura ou em horários de pouca carga, para não disputar recurso com a instância em produção.

Quando não vale a pena

Seja honesto com a sua necessidade antes de adicionar um componente:

• Projeto pequeno, um número, sem exigência de dados: o armazenamento padrão resolve e é um item a menos para manter.
• Você só quer o histórico exportado de vez em quando: a exportação pela API atende, como em histórico de conversas pela API.
• Ninguém no time cuida de banco: um MongoDB sem backup e sem monitoramento é pior que o padrão gerenciado.

MongoDB próprio é para quando os dados são parte do produto ou do contrato.

E o número, fica mais seguro?

Onde os dados ficam não muda como o WhatsApp enxerga o número. A proteção do número vem do comportamento: falar com quem pediu, em ritmo humano, e parar quando a instância dá sinal de risco. A plataforma ajuda com identidade de dispositivo própria por instância, reconexão espaçada e o evento de saúde no webhook de conexão. A WAME não apoia spam, e para uso legítimo a taxa de bloqueio é muito baixa quando o uso é o certo. O que realmente derruba número está em a API não oficial bane?

Conclusão

Conectar um MongoDB próprio à API não oficial do WhatsApp é um POST /instance/mongodb com URI e nome do banco — e, a partir daí, sessão e mensagens ficam onde você decide, com a retenção, o backup e o acesso que você define. Use um banco e um usuário por instância, trate a URI como segredo, transforme a política de retenção em rotina e apague mídia com DELETE /actions/storage quando for a hora. Para quem vende integração ou responde a exigências de compliance, é a diferença entre "confia na gente" e "os dados estão no seu banco". Os detalhes estão na documentação.