---
title: "MongoDB próprio na API do WhatsApp: seus dados de sessão e mensagens no seu banco"
description: "Como conectar seu próprio MongoDB à API não oficial do WhatsApp para guardar sessão e mensagens no seu banco: por que fazer, segurança e LGPD."
url: "https://wame.api.br/blog/mongodb-proprio-whatsapp-api-dados"
language: "pt-BR"
og:type: "article"
published_time: "2026-09-28"
modified_time: "2026-09-28"
author: "Raphael Serafim"
keywords: "api whatsapp não oficial, api não oficial whatsapp, mongodb whatsapp api, armazenar mensagens whatsapp banco de dados, whatsapp api dados próprios, mongodb atlas whatsapp, whatsapp api lgpd dados"
reading_time: "8 min de leitura"
---

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

> Como conectar seu próprio MongoDB à API não oficial do WhatsApp para guardar sessão e mensagens no seu banco: por que fazer, segurança e LGPD.

**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](/blog/rag-whatsapp-base-conhecimento-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](/docs).
4. Copie a URI de conexão (`mongodb+srv://usuario:senha@cluster.exemplo.mongodb.net`).

Depois, conecte a instância:

```bash
curl -X POST "https://server.wame.api.br/SUA_KEY/instance/mongodb" \
  -H "Content-Type: application/json" \
  -d '{
    "uri": "mongodb+srv://wame_loja:SENHA_FORTE@cluster.exemplo.mongodb.net/?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](/blog/provisionar-whatsapp-multiplos-clientes-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](/blog/seguranca-api-whatsapp-token-webhook).

## 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:

```bash
curl -X DELETE "https://server.wame.api.br/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](/blog/whatsapp-api-lgpd-contrato-cliente).

## 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:

```js
// 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](/blog/historico-conversas-whatsapp-api-exportar).
- **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?](/blog/api-whatsapp-nao-oficial-bane-o-que-derruba-numero)

## 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](/docs).

## Perguntas frequentes

### Posso guardar as mensagens do WhatsApp no meu próprio MongoDB?

Sim. Na API não oficial da WAME, faça um POST em /{key}/instance/mongodb com a URI de conexão ('uri') e o nome do banco ('dbName'). A instância passa a usar esse MongoDB para o armazenamento de sessão e de mensagens.

### Por que usar um MongoDB próprio em vez do armazenamento padrão?

Para ter controle dos dados: você decide onde ficam, por quanto tempo, quem acessa e como faz backup. Isso ajuda em exigências de LGPD e de contrato com clientes, e permite análises diretas no banco sem passar pela API.

### Funciona com MongoDB Atlas?

Sim. Use a URI de conexão do Atlas (mongodb+srv://...) com um usuário dedicado para a instância e libere o acesso de rede conforme orientação da documentação. Qualquer MongoDB acessível pela internet com TLS funciona.

### Quais cuidados de segurança devo ter?

Crie um usuário exclusivo com permissão só no banco da instância, use senha forte e conexão com TLS, restrinja o acesso de rede, habilite backup e trate a URI como segredo — ela dá acesso a sessão e mensagens. Nunca reutilize o usuário administrador do cluster.

### E as mídias (fotos, áudios, documentos)?

Os arquivos de mídia salvos pela instância ficam no storage de mídia. Para apagar todos de uma vez, use DELETE /{key}/actions/storage — a exclusão é permanente. Para política de retenção, combine isso com a sua rotina de limpeza.