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

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:

POST https://us.api-wa.me/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:

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://api-wa.me/docs/webhooks.md, e a especificação OpenAPI com todos os campos de todos os endpoints está aberta em https://us.api-wa.me/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. 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://api-wa.me/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: o Direct do Instagram costuma aparecer nessa lista antes do que você espera.