---
title: "Seu SaaS não precisa só de WhatsApp: Instagram e Messenger entram pela mesma porta"
description: "Instagram Direct e Messenger não são dois projetos novos. É a mesma conta, a mesma credencial e o mesmo webhook. O que muda é o seu modelo de dados."
url: "https://wame.api.br/blog/instagram-e-messenger-no-seu-saas"
language: "pt-BR"
og:type: "article"
published_time: "2026-09-23"
modified_time: "2026-09-23"
author: "Raphael Serafim"
keywords: "instagram direct api, messenger api, api whatsapp, multicanal atendimento, webhook whatsapp, micro saas"
reading_time: "11 min de leitura"
---

# Seu SaaS não precisa só de WhatsApp: Instagram e Messenger entram pela mesma porta

> Instagram Direct e Messenger não são dois projetos novos. É a mesma conta, a mesma credencial e o mesmo webhook. O que muda é o seu modelo de dados.

Você resolveu o WhatsApp. Levou algumas semanas, quebrou a cara com a janela de 24 horas, aprendeu que webhook chega duas vezes, e hoje o canal funciona. Aí o primeiro cliente pergunta se dá para responder o Direct do Instagram pelo mesmo painel. E a sua conta, antes de qualquer coisa, é: mais duas integrações, mais dois webhooks, mais dois formatos de mensagem, mais um mês.

Essa conta está errada, e por um motivo específico: os três canais pertencem à mesma empresa. Instagram Direct e Messenger são produtos da Meta, expostos pela mesma plataforma de mensageria que entrega o WhatsApp oficial. Quando o seu provedor normaliza isso, o que sobra para você fazer não é integração nenhuma — é uma decisão de modelagem que você provavelmente tomou errado lá atrás, quando assumiu que todo contato tem telefone.

## As três portas são a mesma porta

Uma conta oficial da Meta carrega os três canais no mesmo par de credenciais. É o mesmo endereço de servidor e a mesma chave que você já usa para mandar no WhatsApp. Não há um segundo cadastro, uma segunda aprovação, um segundo token para guardar.

No envio, o que distingue um canal do outro é um campo. Em vez de criar um cliente novo para cada rede, você acrescenta `provider` ao corpo:

```json
POST https://server.wame.api.br/YOUR_KEY/message/text

{
  "to": "17841400000000000",
  "text": "Recebemos seu pedido, já estamos separando",
  "provider": "instagram"
}
```

Troque `instagram` por `messenger` e a mensagem sai pelo Messenger. Omita o campo e sai pelo WhatsApp, que é o padrão. No SDK de Node e TypeScript é a mesma linha:

```typescript
await wa.message.send({
  type: TypeMessage.TEXT,
  body: { to, text: 'Recebemos seu pedido', provider: 'instagram' },
});
```

Na entrada, o desenho é ainda mais direto. O webhook chega no envelope da Cloud API da Meta — o mesmo formato, independentemente de onde a mensagem veio — com um campo `provider` no topo dizendo qual rede originou aquele evento. O seu handler de webhook não ganha um `if` por canal; ele ganha uma leitura a mais e grava o valor.

Isso significa que o trabalho que você já fez continua valendo inteiro. A idempotência por id externo, a escada de status de entrega, a fila de envio, o proxy de mídia: nada disso se duplica. Se você quiser ver o formato do envelope antes de acreditar, ele está descrito em `https://wame.api.br/docs/webhooks.md`, e a especificação OpenAPI com todos os campos de todos os endpoints está aberta em `https://server.wame.api.br/docs/swagger.json`. Nenhum dos dois exige conta.

## O que não muda

Vale listar, porque a lista do que não muda é maior do que a do que muda:

- **O endpoint de envio.** Mesma rota, mesmo corpo, mais um campo.
- **O formato do webhook.** Mesmo envelope, mesma estrutura de `entry` e `changes`.
- **Os tipos de mensagem.** Texto, imagem, vídeo, áudio, documento. Os três canais aceitam mídia.
- **O recibo de entrega.** Continua chegando como evento de status, e continua só avançando.
- **A reentrega.** A plataforma continua reentregando webhook que não recebeu confirmação. A sua trava de idempotência continua sendo obrigatória.
- **A janela de conversa.** Existe nos três. Não é privilégio do WhatsApp.

Se você tratou o canal como uma camada isolada no seu sistema — uma função que recebe destinatário e conteúdo e devolve um id de mensagem —, acrescentar Instagram e Messenger é acrescentar um parâmetro a essa função. Se você espalhou chamadas de envio por dez lugares do código, é aí que vai doer, e o problema nunca foi o Instagram.

## O que muda: o contato deixa de ser um telefone

Aqui está a parte que ninguém avisa, e ela é de modelagem, não de integração.

No WhatsApp, a pessoa é um número. `5511999999999`. Esse número tem propriedades úteis que você usou sem perceber: ele é digitável, é memorizável, existe fora do seu sistema, pode ser importado de uma agenda, pode ser colado numa planilha, e serve para o cliente do seu cliente falar "manda pro 11 9 9999-9999".

No Instagram e no Messenger, a pessoa é um id opaco da Meta. No Instagram, um `IG_USER_ID`; no Messenger, um `PSID`. São sequências numéricas longas, geradas pela Meta, específicas da combinação entre aquela pessoa e aquela conta de negócio. Elas não são digitáveis, não são memorizáveis, não existem em agenda nenhuma, e não servem para nada fora da sua integração.

### O que isso faz no seu banco

Se o seu contato tem uma coluna `telefone` marcada como obrigatória, ela está errada a partir de agora. O caminho que funciona é o seguinte:

1. **O identificador do canal vira um campo próprio**, não o telefone. Chame de `external_id`, `channel_id`, o nome que quiser — é o valor que o webhook entrega no campo de remetente, cru, sem tratamento.
2. **O telefone vira opcional**, e passa a ser um atributo do contato como o e-mail: existe quando existe.
3. **A chave única é a combinação `canal + identificador + conexão`**, nunca o identificador sozinho. A mesma pessoa pode escrever pelo Instagram e pelo WhatsApp, e para a Meta são duas pessoas diferentes — não há como saber que são a mesma sem que ela mesma diga.

O terceiro ponto costuma gerar resistência, porque parece derrota. É a realidade do dado: a Meta não entrega ponte entre o `IG_USER_ID` e o telefone da mesma pessoa, e qualquer unificação é aposta sua. Deixe-a ser uma ação explícita — um botão de "é a mesma pessoa" — em vez de uma regra automática que junta homônimos no mesmo cadastro.

### O que isso faz na sua tela

Três coisas quebram na interface, e as três são visíveis:

**Não há campo de telefone para digitar.** Toda tela de "iniciar conversa" que você desenhou com um input de número não funciona para Instagram e Messenger. Não existe número. A conversa nesses canais começa quando a pessoa escreve — e só. Se o seu produto tem um botão de "nova conversa", ele precisa ou ficar restrito ao WhatsApp, ou oferecer como destinatário apenas contatos que já escreveram alguma vez.

**Não há agenda de onde importar.** A importação de contatos que você fez para o WhatsApp é telefônica por natureza. Nos outros dois a base se forma sozinha, mensagem a mensagem.

**O nome de exibição é o que você tem.** Sem número visível, a lista de conversas precisa se apoiar no nome e na foto que a Meta entrega, e num selo dizendo de qual canal aquela linha veio. Uma lista onde duas conversas parecem idênticas porque a mesma pessoa escreveu por duas redes é confusão garantida para o atendente — o selo não é enfeite, é o que diz por onde ele deve responder.

Desenhe o selo desde o primeiro dia, mesmo só com WhatsApp ligado: acrescentar um canal a uma lista que já os distingue custa uma linha; acrescentar a distinção depois custa retrabalho em todo lugar que renderiza conversa.

## A janela de 24 horas vale ali também, e não do mesmo jeito

A regra que mais atrapalha no WhatsApp continua valendo: passadas 24 horas da última mensagem da pessoa, você não manda texto livre. É regra da Meta, não do provedor, e ela existe para que sistema automatizado não persiga ninguém.

A diferença é o que você tem para contornar. No WhatsApp, existe o modelo aprovado — você submete o texto, a Meta aprova, e ele pode ser enviado fora da janela mediante pagamento por conversa. Instagram e Messenger não têm um catálogo de modelos aprovados equivalente. As exceções que existem ali seguem outras regras da Meta, e elas mudam com mais frequência do que um artigo consegue acompanhar.

A consequência prática para o seu produto é direta e você deve escrevê-la na documentação antes que um cliente descubra sozinho: **campanha e disparo programado são recursos de WhatsApp**. Nos outros dois canais, o seu sistema responde; ele não inicia. Prometer o contrário na tela de vendas é criar um chamado de suporte para daqui a duas semanas.

Se for desenhar qualquer disparo fora da janela nesses canais, confira a regra vigente na documentação antes de implementar. O custo de errar aqui é a conta do cliente ser restringida.

## Por que este texto não é o mesmo que o da API

Existe outro artigo aqui que trata do mesmo assunto: [API de Instagram e Messenger na mesma API do WhatsApp: uma instância, um padrão](/blog/api-instagram-messenger-mesma-api-whatsapp). Ele é o lado da API — quais endpoints, qual payload, como o `provider` viaja, o que a instância precisa ter configurado. Se a sua pergunta é "como eu chamo isso", é esse o texto, e ele resolve.

Este aqui é o lado do produto. A pergunta que ele responde não é como chamar, e sim **o que acontece com o seu sistema depois que você chama**: qual coluna vira opcional, qual chave única muda, qual tela para de funcionar, qual recurso você não pode vender. Nada disso aparece na especificação, porque não é assunto de API — é assunto de quem mantém o banco e a interface do outro lado.

Leia os dois na ordem que fizer sentido: se ainda não integrou, comece pelo outro; se já tem WhatsApp e está calculando o custo de acrescentar os outros dois, ele está descrito aqui, e é quase todo de modelagem.

## O que fazer primeiro se o WhatsApp já funciona

Uma ordem que evita retrabalho:

1. **Acrescente `canal` na conversa, não na conexão.** A mesma conta oficial recebe pelos três, e a conversa é que sabe por onde veio. Se você gravar o canal na conexão, ele vira o canal de quem escreveu por último — e aí toda decisão tomada a partir dele fica errada de forma intermitente, que é a pior forma de ficar errado.
2. **Solte a obrigatoriedade do telefone** no contato e crie o identificador de canal.
3. **Refaça a chave única** para `canal + identificador + conexão`.
4. **Leia o `provider` do webhook** e grave. Uma linha.
5. **Passe o `provider` no envio**, tirando o valor da conversa e nunca da conexão.
6. **Esconda o botão de iniciar conversa** quando a conversa é de Instagram ou Messenger.

Os passos 4 e 5 são de horas. Os passos 1 a 3 são de dias, e são os que você pagaria de qualquer jeito no dia em que o segundo canal entrasse. Fazer agora, com uma base pequena, é ordens de grandeza mais barato do que fazer com trinta mil contatos gravados.

Se você está conduzindo esse trabalho com um assistente de código, vale dar a ele o mapa da documentação em `https://wame.api.br/llms.txt` antes de pedir qualquer coisa. A diferença entre um modelo que conhece o campo `provider` e um que inventa dois clientes separados é literalmente esse arquivo.

## Conclusão

Instagram e Messenger não são dois projetos. São um campo no envio, um campo no webhook e uma decisão de modelagem que você já devia ter tomado: o contato do seu sistema não é um telefone, é uma pessoa alcançável por algum canal — e o telefone é só um dos endereços possíveis dela.

Quem trata o canal como camada isolada acrescenta os outros dois em um dia. Quem assumiu telefone como identidade paga a refatoração agora ou paga depois, com mais dados dentro. A parte de integração é a parte fácil; a parte difícil é a coluna que você marcou como obrigatória seis meses atrás.

E tem o lado comercial, que é o que o seu cliente enxerga: um painel que responde os três canais no mesmo lugar é um argumento de venda, e um painel que responde só o WhatsApp é um item de comparação que você perde. Com o canal bem separado do resto, fechar essa lacuna custa menos que a reunião em que você vai explicar por que ela existe. Vale ler, ao lado deste, [o que o cliente pede na primeira semana](/blog/crm-feito-com-ia-o-que-o-cliente-pede-na-primeira-semana): o Direct do Instagram costuma aparecer nessa lista antes do que você espera.

## Perguntas frequentes

### Preciso de uma conta da Meta separada para o Instagram?

Não. Instagram Direct e Messenger vêm da mesma conta oficial que você já usa no WhatsApp, com o mesmo par de credenciais. O que é preciso é que a conta do Instagram seja profissional e esteja vinculada à página e ao portfólio de negócios da Meta, e que as permissões de mensageria estejam concedidas. Não há um segundo cadastro de provedor nem uma segunda chave para guardar no seu sistema.

### Dá para usar Instagram e Messenger com a conexão não oficial?

Não. A conexão não oficial é uma sessão de WhatsApp, e só entrega WhatsApp. Instagram e Messenger existem apenas pela via oficial da Meta. Se o seu produto vende os três canais, a conta oficial deixa de ser opção e vira requisito.

### Como eu sei se a mensagem veio do Instagram ou do WhatsApp?

Pelo campo `provider` que chega no topo do envelope do webhook. Ele vale `whatsapp`, `instagram` ou `messenger`. Grave esse valor na conversa no momento em que ela nasce e use sempre o da conversa para decidir por onde responder — nunca o da conexão, que é a mesma para os três.

### Consigo iniciar uma conversa no Instagram como faço no WhatsApp com template?

Não do mesmo jeito. O catálogo de modelos aprovados é um recurso do WhatsApp; Instagram e Messenger não têm equivalente direto, e as exceções à janela de 24 horas nesses canais seguem outras regras da Meta. Na prática, trate campanha e disparo agendado como recursos exclusivos de WhatsApp e deixe isso explícito na sua documentação.

### O mesmo cliente que escreve pelo Instagram e pelo WhatsApp vira dois contatos?

Vira, e isso é correto do ponto de vista do dado. A Meta não entrega nenhuma ponte entre o id do Instagram e o telefone da mesma pessoa. Se quiser unificar, faça disso uma ação explícita no painel, conduzida por um humano com alguma evidência — nunca uma regra automática por nome, que junta homônimos e mistura o histórico de dois clientes.