# API de Conversões do Meta para e-commerce: o que enviar além do Purchase

Por Thiago Morello (Fundador da MyMetric) · guia mantido, atualizado em 11 de outubro de 2026 · https://mymetric.com.br/blog/api-de-conversoes-meta-ecommerce/

## Resumo

- A API de Conversões manda os eventos do servidor da loja direto para o Meta, sem depender do navegador. Ela complementa o pixel, não substitui.
- Deduplicação é obrigatória: pixel e servidor mandam o mesmo event_id, e o Meta conta uma vez só.
- O que mais ajuda o Meta a reconhecer a pessoa: e-mail e telefone (com hash), o identificador do clique (fbc), o ID do navegador (fbp), um external_id, IP e user agent.
- Enviar só o Purchase desperdiça a API. Quando herdamos o e-mail ao longo da jornada, o checkout iniciado com e-mail foi de 40% para 80% e o adicionar ao carrinho de 0% para 35%.
- Envie só pedido pago como Purchase, ou o cancelado vira venda no Meta.

A API de Conversões do Meta (CAPI) virou item obrigatório de checklist. O problema é que muita loja liga a API, manda só a compra e acha que resolveu. Este guia mostra o que enviar, como deduplicar e o que medimos quando a API é usada inteira.

## O que é, em uma frase

A API de Conversões envia os eventos do servidor da loja direto para o Meta. O pixel depende do navegador da pessoa (e perde muito em iPhone dentro do app do Instagram); a API não.

Ela complementa o pixel. O Meta recomenda os dois juntos, com deduplicação.

## Quais eventos enviar

| Evento | Quando | Por que importa |
|---|---|---|
| PageView | Toda página | Base do connect rate e dos públicos |
| ViewContent | Página de produto | Catálogo e públicos de produto |
| AddToCart | Adicionar ao carrinho | Sinal forte de intenção |
| InitiateCheckout | Início do checkout | Onde a pessoa costuma deixar e-mail |
| Purchase | Pedido **pago** | O evento que as campanhas otimizam |

Enviar só o Purchase desperdiça a API: o Meta aprende muito mais cedo na jornada, e é nos eventos do meio que o navegador mais perde.

## Deduplicação: o passo que mais dá errado

Quando pixel e servidor enviam o mesmo evento, o Meta precisa saber que é um só. A regra:

1. Gerar um `event_id` único no navegador para cada evento.
2. Enviar o mesmo `event_id` e o mesmo nome de evento pelo pixel e pela API.
3. O Meta mantém um e descarta o outro.

Sem isso, a compra conta duas vezes e o ROAS dobra do nada. Com o `event_id` diferente nos dois lados, dá no mesmo. Vimos isso na prática: nos três primeiros dias de uma troca de trackeamento, o PageView saiu duplicado até corrigirmos a deduplicação, e esses dias tiveram de ficar fora das medições.

## Parâmetros que ajudam o Meta a reconhecer a pessoa

- **E-mail e telefone**, normalizados e com hash SHA-256.
- **fbc**, o identificador do clique no anúncio (vem do `fbclid` da URL).
- **fbp**, o cookie do pixel.
- **external_id**, o seu ID da pessoa (com hash).
- **IP e user agent** do navegador, não do servidor.

Quanto mais eventos levam esses dados, mais pessoas o Meta consegue ligar a um perfil, e melhor a campanha otimiza.

## O que medimos ao herdar a identidade

O problema: a pessoa só deixa o e-mail no checkout. Os eventos anteriores (visita, produto, carrinho) chegam ao Meta sem e-mail. No Spark, guardamos a identidade quando ela aparece e passamos a enviá-la junto com os eventos seguintes da mesma pessoa. Resultado num cliente, em eventos com e-mail:

| Evento | Antes | Depois |
|---|---|---|
| PageView | 0% | 20% |
| ViewContent | 0% | 9% |
| AddToCart | 0% | 35% |
| InitiateCheckout | 40% | 80% |

E 99,9% das compras saíram com o ID do navegador ligado ao checkout.

Um resultado que não melhorou, e vale contar: herdar o `fbc` quase não muda nada, porque quem não tem o identificador do clique em geral não veio de anúncio.

## Só pedido pago vira compra

O pixel dispara a compra quando o pedido é criado. Se ele for cancelado ou recusado no pagamento, o Meta já contou. Pela API dá para enviar a compra só quando o pedido for pago. Numa loja que atendemos, isso tirou da conta do Meta pedidos cancelados que vinham inflando a receita todo mês.

## Checklist

1. Pixel e API ativos, com o mesmo `event_id` nos dois.
2. Funil inteiro pela API, não só a compra.
3. E-mail, telefone, fbc, fbp, external_id, IP e user agent sempre que existirem.
4. Purchase só de pedido pago.
5. Conferir o [connect rate](https://mymetric.com.br/blog/connect-rate-meta-ads/) antes e depois.

Fazer isso com o GTM server-side é possível, mas dá trabalho e depende da tag do navegador: comparamos em [Stape ou Spark?](https://mymetric.com.br/blog/stape-ou-spark/). O [Spark](https://mymetric.com.br/spark/) faz tudo isso pronto para e-commerce.

## Perguntas frequentes

### O que é a API de Conversões do Meta?

É a forma de enviar eventos (visita, carrinho, compra) do servidor da empresa direto para o Meta, em vez de depender só do pixel no navegador da pessoa.

### Preciso manter o pixel se usar a API de Conversões?

O Meta recomenda usar os dois, com deduplicação por event_id. O pixel pega sinais do navegador; a API garante o evento quando o navegador falha.

### Como funciona a deduplicação?

O pixel e o servidor enviam o mesmo evento com o mesmo nome e o mesmo event_id. O Meta mantém um e descarta o outro.

### Quais dados melhoram a qualidade da correspondência?

E-mail e telefone com hash SHA-256, fbc (identificador do clique), fbp (cookie do pixel), external_id, IP e user agent. Quanto mais eventos levarem esses dados, mais pessoas o Meta reconhece.

### Devo enviar pedido cancelado?

Não como Purchase. O ideal é enviar só o pedido pago, ou o Meta vai otimizar para vendas que não aconteceram.