Se você anuncia no Meta para vender curso, mentoria ou e-book, já ouviu que precisa “ligar a API de Conversões”. Às vezes como conselho, às vezes como bronca de quem olhou sua conta. O que quase ninguém explica é o que ela faz de diferente do pixel, o que precisa ser enviado para ela funcionar bem, e os dois erros que fazem ela atrapalhar em vez de ajudar.
O que é a API de Conversões
O pixel da Meta é um script que roda no navegador de quem visita sua página. A API de Conversões (CAPI, no apelido em inglês) é o mesmo tipo de informação — “essa pessoa comprou, por esse valor” — enviada de um servidor para a Meta, sem passar pelo navegador do comprador.
- Pixel no navegadorvê a navegação na página
- Plataforma confirma a vendaHotmart, Kiwify, Cakto, Wiapy
- Servidor envia pela CAPInão depende do navegador
- A Meta junta os doise descarta a repetição
Para quem vende infoproduto, o servidor tem uma vantagem natural: quem sabe com certeza que houve venda é a plataforma de pagamento, não a página. O Pix pago no dia seguinte, o boleto compensado em dois dias, a compra feita com bloqueador de anúncio ligado — tudo isso a plataforma confirma, e o pixel do navegador pode nunca ver. O porquê disso está detalhado em rastreamento server-side vs pixel do navegador.
O que precisa ir junto com o evento
Mandar só “houve uma compra de R$ 97” não adianta muito. A Meta precisa descobrir quem comprou para ligar a venda ao anúncio que essa pessoa viu — e ela faz isso comparando dados do comprador com os das contas dela. São os parâmetros de correspondência:
| Dado | Como vai | De onde costuma vir |
|---|---|---|
| em hash (SHA-256) | plataforma de vendas | |
| Telefone | em hash, com o código do país | plataforma de vendas |
| Nome, cidade, estado, CEP, país | em hash | plataforma de vendas |
| IP e navegador (user agent) | sem hash | página ou checkout |
fbp | sem hash | cookie do pixel na página |
fbc | sem hash | o clique no anúncio (fbclid) |
| Id externo | em hash | o visitante na sua ferramenta |
Quanto mais desses chegam, mais fácil para a Meta casar a venda — é o que aparece como nota de qualidade no Gerenciador de Eventos. Os detalhes de cada parâmetro e os erros que derrubam essa nota estão em pontuação de qualidade do evento.
O erro que mais aparece: Purchase em dobro
Mandar o mesmo evento pelos dois caminhos — navegador e servidor — é o desenho previsto. A Meta junta os dois quando eles chegam com o mesmo nome e o mesmo identificador (o event_id), e fica com um só.
O problema aparece quando duas ferramentas diferentes mandam a compra pelo servidor. É um cenário comum: a plataforma de vendas tem integração própria com a API de Conversões, e a ferramenta de rastreamento também manda. Cada uma gera o seu identificador, e para a Meta isso são duas compras.
Duas fontes, duas compras
Se a sua plataforma de vendas já manda o Purchase para a Meta e você liga outra ferramenta que também manda, confira no Gerenciador de Eventos se as compras não dobraram. O sintoma é um ROAS no Gerenciador bom demais para ser verdade, e uma campanha otimizando para compras que não existiram. Escolha uma fonte para o Purchase e desligue a outra.
O outro erro: evento atrasado demais
A API de Conversões aceita eventos de até 7 dias atrás. Mais que isso, a Meta recusa — e, se o evento atrasado vier junto com outros na mesma chamada, recusa o lote inteiro. Isso importa para quem reprocessa vendas antigas ou importa histórico: venda velha não volta para a Meta, e não adianta insistir.
Como configurar, no caminho mais curto
1. Gere o token no Gerenciador de Eventos
No Gerenciador de Eventos, abra o seu pixel, vá em configurações e procure a seção da API de Conversões. Lá existe a opção de gerar um token de acesso. Esse token é o que autoriza um servidor a mandar eventos em nome do seu pixel.
Trate o token como senha
Quem tem o token consegue mandar eventos para o seu pixel. Não cole em grupo, não mande em print, não deixe em planilha compartilhada. Se vazar, gere outro e substitua onde ele estiver configurado.
2. Escolha quem vai mandar a compra
Pode ser a integração nativa da plataforma de vendas ou uma ferramenta de rastreamento — o importante, como visto acima, é ser uma só. A vantagem de uma ferramenta que também rastreia o clique é poder mandar junto os dados que só a página conhece, como o fbc do clique e o id do visitante, além dos que a plataforma conhece.
3. Teste antes de confiar
O Gerenciador de Eventos tem uma aba de eventos de teste, que mostra os eventos chegando em tempo real. Faça uma compra de teste e confira três coisas:
- O Purchase chegou pelo servidor — a coluna de origem mostra se veio do navegador ou do servidor.
- Chegou uma vez só, e não duas.
- O valor e a moeda estão certos. Um valor em centavos lido como reais, ou uma comissão em dólar lida como real, distorce tudo o que a Meta aprende.
Em uma frase
A API de Conversões leva a venda confirmada pela plataforma até a Meta sem depender do navegador — e funciona bem quando vai com os dados do comprador, sai de uma fonte só e chega dentro de 7 dias.
A compra sai do servidor, uma vez só
O UTMizey recebe a venda pelo webhook da plataforma e manda o Purchase pela API de Conversões com os dados de correspondência do comprador e do clique. Cada venda vai com um identificador próprio, então o reenvio do webhook não vira compra repetida — e venda com mais de 7 dias não é enviada. A configuração é colar o token do pixel no painel.