API de Conversões (CAPI): o que é e como funciona

Se você já viu a sigla CAPI em qualquer conversa sobre Meta Ads e ficou com dúvida do que exatamente ela resolve, este guia é pra isso. E se seu funil passa por Telegram, vale prestar atenção: aqui, CAPI não é um recurso avançado opcional — é o único jeito de fechar o rastreamento de conversão de verdade.

O que é a API de Conversões (CAPI)

A API de Conversões é o mecanismo que permite enviar eventos de conversão pro Meta Ads diretamente do servidor, sem depender de um script rodando no navegador de quem converteu. Ela existe, em boa parte, como resposta a um problema que cresceu nos últimos anos: bloqueadores de anúncio, restrições de rastreamento em navegador (como o App Tracking Transparency da Apple) e políticas de privacidade cada vez mais restritivas reduziram a confiabilidade só do rastreamento client-side (via Pixel). O Meta passou a incentivar fortemente o uso combinado de Pixel e CAPI justamente pra compensar essa perda de sinal client-side com um canal mais resistente, que não depende do que acontece (ou deixa de acontecer) no navegador do usuário.

Em termos simples: o Pixel conta o que ele consegue observar de dentro do navegador; o CAPI conta o que o seu próprio sistema sabe que aconteceu, independente do que o navegador reportou (ou deixou de reportar).

CAPI vs Pixel: o que muda

O Pixel roda no navegador de quem visita sua página — é código JavaScript que dispara um evento (PageView, Lead, Purchase) no momento em que algo acontece na tela. O CAPI faz a mesma coisa conceitualmente (informa ao Meta que um evento de conversão aconteceu), mas via uma chamada HTTP autenticada, feita pelo servidor, sem passar pelo navegador em nenhum momento.

Na maioria dos funis web, a recomendação é rodar os dois ao mesmo tempo: o Pixel captura o que consegue no navegador, o CAPI reforça com o mesmo evento (ou eventos que o navegador não conseguiu capturar), e os dois se deduplica via event_id compartilhado — cobrindo as lacunas um do outro.

CAPI em diferentes contextos de funil

Vale situar onde o CAPI se encaixa em cada tipo de funil, porque a “obrigatoriedade” dele muda bastante:

• Site/e-commerce comum: o Pixel funciona, mesmo que com perda de sinal variável (bloqueadores, navegadores mais restritivos). CAPI complementa, reforçando o que o Pixel perde.
• App mobile: o rastreamento tende a depender mais de SDKs específicas de mobile measurement, mas o princípio de complementar sinal client-side com server-side se mantém.
• Telegram: não existe navegador nem SDK de app rodando durante a interação dentro do canal — CAPI deixa de ser complemento e vira o único canal de sinal possível pro evento de entrada/saída/depósito.

Por que no Telegram o CAPI não é opcional

Aqui está a diferença que importa pra quem roda tráfego pra Telegram: num site comum, mesmo que o Pixel perca sinal por bloqueio de rastreamento, ele ainda tem uma página rodando, um navegador, um DOM. No Telegram, depois que a pessoa sai do seu site (ou da sua página intermediária) e entra no app do Telegram, não existe navegador nenhum acompanhando o que acontece — o evento de entrada no canal só existe dentro da própria API do Telegram, observável por um bot.

Isso significa que não tem “Pixel reforçado por CAPI” pra esse evento específico — o CAPI é a única forma de esse dado chegar ao Meta. Ver o guia de Pixel/CAPI no Telegram pro fluxo técnico completo desse caso.

Como funciona tecnicamente

Uma chamada de evento pra CAPI carrega, no mínimo: o nome do evento (Lead, Purchase, ou um evento personalizado), o momento em que aconteceu de verdade (não o momento do envio), a origem do evento (de onde ele foi gerado — navegador, sistema, chat), um identificador de deduplicação (event_id), dados do usuário disponíveis (sempre hasheados em SHA-256 antes do envio) e dados extras de valor, quando aplicável (como o valor de um depósito).

Em estrutura simplificada, uma chamada típica carrega algo como:

event_name: "Lead"
event_time: 1752480000
action_source: "system_generated"
event_id: "abc123"
user_data: { em: "hash_do_email", client_ip_address: "..." }
custom_data: { value: 50, currency: "BRL" }

Cada implementação (bot próprio, ferramenta dedicada) monta essa estrutura de um jeito ligeiramente diferente por baixo dos panos, mas os campos conceituais são sempre esses. Ver o guia de Pixel/CAPI no Telegram pra um passo a passo detalhado desses campos aplicado ao caso específico de entrada de canal.

Por que os dados do usuário precisam vir hasheados

Quando a chamada inclui e-mail, telefone ou outro dado pessoal, a Meta exige que venha processado em SHA-256 — uma função que transforma o dado original numa sequência de caracteres irreversível. Isso permite que a Meta compare o hash recebido com hashes que ela já tem (de contas de usuário, por exemplo) sem que o dado pessoal em si trafegue ou fique armazenado em texto puro em nenhum momento do processo.

Deduplicação e Event Match Quality, explicados

Deduplicação é o mecanismo que impede o Meta de contar duas vezes o mesmo evento quando ele chega tanto via Pixel quanto via CAPI — os dois precisam compartilhar o mesmo event_id pra o Meta entender que são a mesma conversão vista por dois caminhos.

Event Match Quality (EMQ) é a nota que o Meta dá pra quão bem ele consegue associar aquele evento a uma pessoa/anúncio específico, com base em quantos campos de user_data a chamada inclui (e-mail, telefone, IP, cookies do Pixel). Quanto mais completo o conjunto de dados enviado, mais alto tende a ser o EMQ — e eventos com EMQ baixo tendem a contribuir menos pra otimização de campanha, mesmo estando “corretos”.

Vale a pena acompanhar essa nota no Gerenciador de Eventos periodicamente, não só configurar uma vez e esquecer: mudanças na sua página, no bot ou na forma como os dados são coletados podem impactar o EMQ ao longo do tempo, silenciosamente, sem nenhum erro visível — só uma piora gradual na qualidade da otimização.

Erros comuns de quem está aprendendo CAPI agora

• Confundir CAPI com “melhoria” do Pixel: em contextos onde não existe navegador (como Telegram), CAPI não melhora nada — é o único caminho.
• Não hashear dados do usuário: a Meta exige SHA-256 pra qualquer dado pessoal enviado via user_data — texto puro faz a chamada ser rejeitada.
• Testar só em produção: o Gerenciador de Eventos do Meta tem uma aba de Eventos de Teste especificamente pra validar chamadas de CAPI antes de rodar campanha de verdade com elas.
• Ignorar o event_time correto: o timestamp deve refletir quando o evento aconteceu de fato, não quando a chamada de API foi processada.
• Esquecer o event_id compartilhado: sem ele, Pixel e CAPI reportam o mesmo evento como se fossem dois — inflando artificialmente o resultado da campanha.
• Mandar poucos campos de user_data: uma chamada tecnicamente correta, mas com pouquíssimo dado de usuário, ainda assim tende a ter EMQ baixo — vale enviar todos os campos disponíveis, não só o mínimo pra chamada não ser rejeitada.

Onde a Track4you entra nisso

Pro caso específico de Telegram, a Track4you monta e dispara essas chamadas de CAPI prontas — captura do evento de entrada (ou de FTD, via postback), montagem correta dos campos, deduplicação com o Pixel quando aplicável — sem exigir que você implemente a integração técnica descrita acima do zero.

Perguntas frequentes

Termos relacionados (postback, deduplicação, Event Match Quality) também aparecem no glossário.

Conclusão

CAPI não é um recurso avançado pra quem “já domina o básico” — é a peça que fecha o rastreamento em qualquer contexto onde o navegador não está no meio do caminho, e no Telegram esse é sempre o caso. Entender a diferença entre Pixel e CAPI, por que um não substitui o outro em todo contexto, e o que realmente compõe uma chamada de evento bem-feita (nome, tempo, origem, deduplicação, dados de usuário hasheados) é o primeiro passo pra qualquer configuração de rastreamento séria nesse canal — seja você quem vai implementar isso na mão ou só quer entender o que uma ferramenta dedicada está fazendo por trás do painel.