Cole este link na sua IA e ela integra o WhatsApp: o que é um llms.txt

Peça a qualquer assistente de código para integrar o WhatsApp e você vai receber um arquivo caprichado: cliente HTTP tipado, tratamento de erro, comentários. E ele aponta para um endpoint que não existe, com um campo que mudou de nome e uma versão de API que ninguém usa mais.

O problema não é o modelo. É que ninguém disse a ele qual API você vai usar. Ele preencheu o vazio com o que viu no treino — tutoriais de 2023, respostas de fórum, exemplos de bibliotecas que já foram descontinuadas. Existe uma correção de uma linha para isso, e ela se chama llms.txt.

O que é um llms.txt

É um arquivo de texto, em Markdown, na raiz do site, que descreve o que aquele serviço faz e onde está cada coisa. A proposta nasceu em 2024 com a mesma lógica do robots.txt: o robots.txt diz ao rastreador o que ele pode ler; o llms.txt diz ao modelo o que vale a pena ler.

A diferença está no formato. Uma página de documentação em HTML carrega menu de navegação, banner de cookie, rodapé, botão de copiar, marcação de destaque de sintaxe e trezentas linhas de estilo. Nada disso é informação. Quando você manda um agente "ler a documentação", ele baixa tudo, e uma parte grande do contexto — que é finito e caro — vai embora em estrutura de página.

Markdown puro não tem esse desperdício. Um título é um #, um exemplo é um bloco de código, um link é um link. O que sobra é o que interessa: endpoint, campo, formato, regra.

Por que isso muda o resultado da integração de WhatsApp

Integrar WhatsApp tem três coisas que o modelo erra com frequência, e as três são resolvidas por documentação atual:

O endereço. A Cloud API da Meta tem versão no caminho, e o modelo chuta uma. Numa API gerenciada, o endereço é outro e a chave também. Sem documentação, ele inventa uma URL plausível — e plausível não responde.

Os campos. O nome do campo que carrega o destinatário, o que carrega o texto, o que escolhe o canal. Errar um deles devolve 400 com uma mensagem genérica, e você perde uma tarde procurando no lugar errado.

As regras que não são código. A janela de 24 horas é a maior delas: passado esse prazo desde a última mensagem do cliente, iniciar conversa exige template aprovado. Isso não é um parâmetro, é um desenho de produto — e o modelo só vai considerar se estiver escrito na documentação que ele leu.

Os três níveis da WAME

Há três endereços, e eles servem a momentos diferentes.

O mapa: llms.txt

https://api-wa.me/llms.txt é o índice. Ele diz o que a plataforma faz, quais canais atende — WhatsApp, Instagram Direct e Messenger —, quais são os recursos principais e onde encontrar cada referência. É o arquivo que cabe inteiro no contexto sem sacrifício e que serve para o modelo se orientar antes de procurar detalhe.

É também o que você cola primeiro. Se o seu editor aceita só um link, é esse.

A referência completa: llms-full.txt

https://api-wa.me/llms-full.txt é a documentação inteira, no mesmo formato. Endpoint por endpoint, com os campos e os exemplos. É maior, então faz sentido quando você está no meio da implementação e precisa que o modelo acerte assinatura, não só direção.

A especificação: swagger.json

https://us.api-wa.me/docs/swagger.json é o OpenAPI. Não é para você ler — é para a máquina. É onde está, de forma inequívoca, quais campos são obrigatórios, qual o tipo de cada um e o que o servidor devolve.

Essa distinção importa mais do que parece. Markdown descreve; OpenAPI define. Quando o modelo precisa decidir se um campo é opcional, a prosa deixa margem e o esquema não. Numa integração real, o campo obrigatório que o exemplo não mostrava é o erro mais caro de todos: ele passa no teste feliz e falha na conta do cliente.

O prompt que você cola

Abra o Cursor, o Claude Code ou o Copilot Chat no projeto e comece por aqui, antes de pedir qualquer código:

Vou integrar mensageria (WhatsApp, Instagram e Messenger) neste projeto
usando a API da WAME.

Leia estes três arquivos antes de escrever qualquer linha:
- https://api-wa.me/llms.txt        (mapa da plataforma)
- https://api-wa.me/llms-full.txt   (referência completa)
- https://us.api-wa.me/docs/swagger.json  (OpenAPI, para os campos)

Regras:
1. Não use nenhum endpoint que não esteja nesses arquivos.
2. Se um campo não estiver no swagger, não invente: pergunte.
3. Considere a janela de 24 horas do WhatsApp: fora dela, iniciar
   conversa exige template aprovado.
4. O webhook pode ser reentregue. Toda ingestão precisa ser idempotente.

Antes de codar, me devolva em uma lista: os endpoints que você vai
chamar, os campos de cada um e onde a janela de 24h entra no meu
modelo de dados.

A última instrução é a mais útil das cinco. Pedir a lista antes do código transforma um arquivo de 200 linhas que você teria que auditar inteiro numa lista de dez itens que você confere em dois minutos. Se algum endpoint estiver errado ali, você corrige antes de ele virar código, teste e commit.

O checklist completo de como conduzir o editor daqui em diante — o que dar, o que pedir e os três erros que a IA repete todo dia nessa integração — está em Cursor, Claude Code e Copilot: fazendo a IA escrever a integração de WhatsApp certa na primeira tentativa.

O que sai do outro lado

Com a documentação em contexto, o envio nos três canais é o mesmo código. Instalando o SDK:

npm install @raphaelvserafim/client-api-whatsapp

O cliente se configura com o servidor da sua instância e a chave:

import { Wame, TypeMessage } from '@raphaelvserafim/client-api-whatsapp';

const wa = new Wame({
  server: 'https://us.api-wa.me',
  key: process.env.WAME_KEY!,
});

await wa.message.send({
  type: TypeMessage.TEXT,
  body: { to, text: 'Seu pedido #1042 saiu para entrega' },
});

Trocar de canal é um campo:

await wa.message.send({
  type: TypeMessage.TEXT,
  body: { to, text: 'Oi', provider: 'instagram' },
});

O que muda entre os canais é o identificador do destinatário: no WhatsApp é o número; no Instagram, o IG_USER_ID; no Messenger, o PSID. A forma de chamar é a mesma, e essa é a parte que o modelo acerta de primeira quando tem a referência na mão — e erra de forma criativa quando não tem.

Do lado de receber, o webhook se aponta pela própria API:

await wa.instance.updateWebhook({
  allowWebhook: true,
  allowNumber: 'all',
  webhookMessage: 'https://seusistema.com/webhook/wame',
  webhookFormat: 'meta',
});

O webhookFormat: 'meta' é a peça que economiza mais código. Ele faz os três canais chegarem no mesmo envelope — o formato da Cloud API da Meta, com um campo provider no topo dizendo de onde veio. Você escreve um parser, não três. O padrão de webhook único para os três canais explica o formato campo a campo.

Se você não usa Node, o mesmo caminho existe em POST https://us.api-wa.me/YOUR_KEY/message/text, com o corpo {"to":"...","text":"...","provider":"instagram"}. O SDK JavaScript e TypeScript e o guia de endpoints cobrem o resto da superfície.

Repare no que não apareceu nesse trecho: nenhuma biblioteca de sessão, nenhum navegador sem interface, nenhum arquivo de credencial em disco, nenhum código de barras para ler com o celular a cada reinício. Isso importa para quem está construindo com assistente de código por um motivo prático: essas peças são exatamente as que o modelo adora propor quando não tem referência, porque são as mais documentadas na internet — e são também as que transformam o seu servidor num serviço com estado, que não escala horizontalmente e que quebra no primeiro deploy feito no meio de uma conversa.

Com a documentação em contexto, o desenho que sai do outro lado é sem estado: uma chave, um endereço, chamadas HTTP e um endpoint seu recebendo eventos. Esse é o formato que cabe num contêiner, que sobrevive a um reinício e que você consegue rodar em duas instâncias ao mesmo tempo sem pensar muito. Nada disso é mérito do modelo; é consequência de ele ter lido a referência certa antes de opinar.

llms.txt não é MCP, e os dois resolvem coisas diferentes

Vale separar, porque os nomes andam juntos e a confusão custa tempo.

O llms.txt é documentação. Ele entra no contexto do seu editor, enquanto você escreve o sistema, e o resultado dele é código-fonte no seu repositório.

O MCP é uma ponte em tempo de execução: o agente ganha ferramentas e passa a fazer coisas — mandar mensagem, ler conversa, checar se um número existe. Na WAME isso se liga com um comando (claude mcp add --transport http wame https://mcp.wame.api.br) e é assunto do artigo sobre MCP na prática.

Resumindo a diferença: o llms.txt ajuda a IA a escrever a integração; o MCP dá à IA o WhatsApp para usar. Se o seu objetivo é ter um sistema seu, com código seu, é o primeiro que importa.

O limite honesto disso

Documentação em contexto corrige o que o modelo não sabe. Ela não corrige o que nenhuma documentação resolve.

A conta na Meta continua sendo criada por uma pessoa, com CNPJ e verificação de negócio. O número precisa estar livre do aplicativo, ou entrar por coexistência. O template passa por análise da Meta e pode ser recusado. Nada disso vira código, e nenhum arquivo colado no editor acelera a fila de aprovação de ninguém.

O que muda é a proporção. Com a documentação certa, a parte de programação some do caminho crítico e sobra só a parte burocrática — que você pelo menos consegue começar no primeiro dia, em vez de descobrir na sexta-feira seguinte.

Conclusão

A instrução "integra o WhatsApp" não tem código como resposta completa, e é por isso que ela produz arquivos bonitos que não rodam. O modelo não está errando: está preenchendo uma lacuna que você deixou.

Fechar a lacuna custa um link. https://api-wa.me/llms.txt para o mapa, llms-full.txt quando precisar da referência inteira, e o swagger.json quando o assunto for campo obrigatório. Cole antes de pedir código, peça a lista de endpoints antes do arquivo, e a primeira mensagem sai no mesmo dia.