# API de conversion Meta (CAPI) : installer, dédupliquer et fiabiliser vos événements

> L’API de conversion Meta (CAPI) transmet vos événements de serveur à serveur, en complément du Pixel. Meta recommande d’envoyer les mêmes événements par les deux canaux avec un event_name et un event_id identiques pour la déduplication (fenêtre de 48 heures), d’ajouter des paramètres clients hachés en SHA-256 pour améliorer la qualité de correspondance (note sur 10) et de respecter le consentement RGPD.

Source : https://creapreneurs.io/blog/api-conversions-meta/  
Auteur : Arthur Moreau, fondateur de Creapreneurs  
Mis à jour : 2026-09-29

L’API de conversion Meta envoie vos conversions depuis votre serveur pour compléter le Pixel. Bien réglée, elle récupère le signal perdu ; mal dédupliquée, elle double vos achats. Voici comment la mettre en place proprement.

## Qu’est-ce que l’API de conversion Meta ?

L’API de conversion Meta (Conversions API, ou CAPI) envoie vos événements marketing depuis votre serveur, votre boutique ou votre CRM directement vers Meta, sans passer par le navigateur de l’internaute. Là où le Pixel s’exécute dans la page, l’API transmet un achat, un lead ou une inscription de serveur à serveur.

Meta décrit l’API comme un pont entre vos données marketing et ses systèmes, utilisé pour optimiser la diffusion des publicités et mesurer leurs résultats (voir la documentation Conversions API). Les événements serveur sont rattachés au même identifiant de jeu de données que le Pixel et traités de la même façon.

Elle ne remplace pas le Pixel, elle le double. C’est la pièce centrale d’un [tracking publicitaire](https://creapreneurs.io/agence-tracking-publicitaire/) solide, parce qu’elle donne à Meta un second canal pour les conversions qui comptent pour votre activité.

## Pourquoi utiliser l’API Conversions en plus du Pixel Meta ?

Parce que le Pixel seul perd des événements. Meta recommande une configuration redondante, avec les mêmes événements envoyés par le Pixel et par l’API, et explique dans ses bonnes pratiques que l’API récupère ceux que le Pixel manque à cause de problèmes de connexion ou d’erreurs de chargement de page.

Dans nos audits, les mêmes causes de perte côté navigateur reviennent, qu’il s’agisse de bloqueurs de publicité, page de confirmation qui ne se charge pas complètement, paiement finalisé sur un domaine tiers, application mobile qui ouvre un navigateur intégré. Le serveur, lui, sait qu’une commande a été payée, quelle que soit la façon dont la page s’est affichée.

Le bénéfice ne se limite pas au volume. Un événement serveur peut porter des informations fiables issues du back-office (valeur réelle de la commande, identifiant client, statut) et des paramètres clients hachés qui améliorent la correspondance avec les comptes Meta. Ce signal plus riche aide l’algorithme à trouver des acheteurs, et permet au travail de notre [agence Meta Ads](https://creapreneurs.io/agence-meta-ads/) à reposer sur des résultats exploitables.

## Comment dédupliquer les événements du Pixel et de l’API ?

Le Pixel et l’API doivent envoyer le même nom d’événement et le même identifiant, *eventID* côté Pixel et *event_id* côté serveur. C’est la méthode que recommande la documentation Meta sur la déduplication.

### Les règles à connaître

- Le nom d’événement du Pixel (*event*) doit correspondre à *event_name* côté API, par exemple Purchase des deux côtés.

- L’identifiant doit distinguer chaque événement : pour un achat, le numéro de commande est le choix le plus robuste.

- Meta ne déduplique que les événements reçus dans les 48 heures qui suivent la réception du premier événement portant cet *event_id*.

- Quand les deux versions ne diffèrent pas réellement, Meta indique conserver en général celle reçue en premier.

Une méthode alternative existe, fondée sur *event_name* combiné à *fbp* ou *external_id*. Elle est moins fiable, car Meta précise qu’un événement serveur n’est pas écarté si aucun événement navigateur identique n’a été reçu au cours des 48 heures précédentes, même si ce dernier arrive ensuite. Nous l’utilisons seulement en dernier recours.

### L’erreur la plus fréquente

Générer l’identifiant deux fois, avec une valeur aléatoire dans le navigateur, une autre sur le serveur. Les deux événements arrivent, aucun ne se reconnaît, et les achats sont doublés dans le gestionnaire de publicités. L’identifiant doit être créé une seule fois, idéalement à partir de la commande, puis transmis aux deux canaux.

## Qu’est-ce que la qualité de correspondance des événements et comment l’améliorer ?

C’est une note sur 10, visible dans le gestionnaire d’événements, qui indique dans quelle mesure les informations client d’un événement permettent à Meta de le rattacher à un compte. D’après ses bonnes pratiques, une meilleure correspondance donne de meilleurs résultats.

La note dépend des paramètres clients transmis avec chaque événement. Meta cite comme paramètres de qualité l’email (*em*), le téléphone (*ph*), l’adresse IP (*client_ip_address*), le prénom et le nom (*fn*, *ln*) ainsi que les cookies *fbp* et *fbc*, dont les valeurs doivent être rafraîchies régulièrement.

### Ce qui doit être haché, et ce qui ne doit pas l’être

La page Customer Information Parameters fixe des règles précises. Les données personnelles comme l’email, le téléphone, le nom, la ville ou le code postal doivent être normalisées (espaces supprimés, minuscules, indicatif pays pour le téléphone) puis hachées en SHA-256. À l’inverse, l’adresse IP, le user agent, *fbc* et *fbp* ne doivent jamais être hachés.

Nous visons la justesse et la conformité avant la note. Nous ajoutons les paramètres disponibles et autorisés, vérifions leur format, puis suivons la note événement par événement, sans courir après un chiffre cible universel.

## Quelles options d’intégration choisir : partenaire, Gateway ou GTM serveur ?

Tout dépend de votre CMS, de vos ressources techniques et du nombre de régies. Sur Shopify, l’intégration native suffit souvent ; un site sur mesure ou un annonceur présent sur plusieurs plateformes justifie une intégration directe ou un conteneur serveur.

### L’intégration partenaire

Sur Shopify, le canal Facebook & Instagram propose trois niveaux de partage de données. D’après l’aide Shopify, le niveau Standard repose sur le Pixel seul, tandis que les niveaux Enhanced et Maximum ajoutent l’API Conversions, dont les données transmises de serveur à serveur ne peuvent pas être bloquées par les bloqueurs de publicité du navigateur. C’est la voie la plus rapide, avec peu de maîtrise sur le détail des événements.

### La Conversions API Gateway

La Conversions API Gateway est une option de configuration en libre-service depuis le gestionnaire d’événements, sans code. Elle est déployée dans un compte cloud appartenant à l’entreprise (AWS ou Google Cloud selon la documentation), et Meta indique que son seul coût correspond aux ressources cloud ou aux frais du partenaire d’hébergement. Pratique quand on veut un envoi serveur sans développement, elle reste centrée sur Meta.

### L’intégration directe ou via Google Tag Manager côté serveur

L’intégration directe consiste à appeler l’API depuis votre back-office. Elle offre le plus de contrôle et convient aux sites sur mesure, aux tunnels de vente et aux leads qualifiés dans un CRM. Un conteneur [Google Tag Manager côté serveur](https://creapreneurs.io/blog/tracking-server-side/) est une variante intéressante quand plusieurs plateformes (Meta, Google, TikTok) doivent recevoir les mêmes événements : un seul flux entrant, redistribué selon des règles communes.

## L’API Conversions est-elle compatible avec le RGPD et le consentement ?

Oui, si elle respecte exactement le choix exprimé dans votre bandeau cookies. Sans consentement aux finalités publicitaires, aucun événement comportant des données personnelles ne doit partir vers Meta, et passer par un serveur n’y change rien. La CNIL exige un consentement préalable pour les traceurs non exemptés (CNIL, que dit la loi).

Le piège classique est l’envoi serveur « aveugle ». L’achat part vers Meta depuis le back-office alors que le client a refusé les cookies publicitaires ; rien ne l’empêche techniquement, mais c’est un contournement du refus. Chez Creapreneurs, nous faisons remonter l’état du consentement jusqu’au serveur et conditionnons l’envoi à cet état.

L’option Limited Data Use de Meta ne règle pas la question, puisqu’elle concerne des États américains et non l’Union européenne (Data Processing Options for US Users). Les règles françaises et leur traduction côté Google sont détaillées dans notre guide sur le [Consent Mode v2](https://creapreneurs.io/blog/consent-mode-v2/). Pixel, API et balises Google doivent lire le même signal de consentement.

## Quels paramètres techniques vérifier avant de mettre en production ?

Cinq paramètres conditionnent l’acceptation et l’utilité des événements : *action_source*, *event_source_url*, *event_time*, *event_id* et la valeur de conversion. Leurs contraintes sont décrites dans les paramètres d’événement serveur de Meta.

- **action_source** est obligatoire et indique où la conversion a eu lieu (website, app, physical_store, system_generated…).

- **event_source_url** est exigé pour les événements web envoyés par l’API.

- **event_time** peut remonter jusqu’à 7 jours avant l’envoi, pas au-delà. Un import tardif depuis un CRM doit en tenir compte.

- **event_id** est facultatif pour Meta, mais indispensable dès que le Pixel envoie le même événement.

- **opt_out**, s’il vaut true, limite l’usage de l’événement à l’attribution et l’exclut de l’optimisation de la diffusion.

Côté valeur, décidez une fois pour toutes ce que vous transmettez, chiffre d’affaires HT ou TTC, avec ou sans frais de port. Le choix importe moins que sa cohérence entre Pixel, API et reporting ; c’est lui qui rend votre [calcul de ROAS](https://creapreneurs.io/blog/calcul-roas-rentabilite/) comparable dans le temps.

## Quelles erreurs faussent le plus souvent une intégration CAPI ?

Les plus coûteuses ne sont pas les pannes visibles, mais les intégrations qui ont l’air de fonctionner tout en envoyant des données fausses. Voici celles que nous retrouvons le plus souvent en reprenant un compte.

- **Deux intégrations en parallèle** : l’application Shopify et un conteneur serveur envoient chacun leurs achats, avec des identifiants différents.

- **Un Purchase envoyé à la création de commande** plutôt qu’au paiement confirmé, ce qui gonfle les ventes avec des commandes abandonnées ou refusées.

- **Une devise ou une valeur absente** : l’événement est reçu, mais inutilisable pour optimiser sur la valeur.

- **Des événements de test oubliés** en production, ou un code de test laissé actif.

- **Des emails non normalisés** avant hachage (majuscules, espaces), qui dégradent silencieusement la correspondance.

Aucune de ces erreurs ne déclenche d’alerte bloquante. Elles se repèrent en comparant régulièrement les chiffres de Meta à ceux du back-office, ce que nous faisons avant toute décision d’augmenter un budget.

## Check-list de recette pour une API de conversion Meta fiable

Une intégration est terminée quand chaque événement clé arrive une seule fois, avec une valeur juste et des paramètres clients conformes, et que vous l’avez vérifié sur de vraies commandes. Voici la liste que nous déroulons en recette.

- Lister les événements utiles au pilotage : PageView, ViewContent, AddToCart, InitiateCheckout, Purchase ou Lead, pas davantage au départ.

- Vérifier que le domaine est validé et que Pixel et API envoient vers le même jeu de données.

- Contrôler, dans le gestionnaire d’événements, que chaque événement apparaît en « navigateur et serveur » et qu’il est bien dédupliqué.

- Passer une commande test et retrouver le même *event_id* des deux côtés.

- Comparer sur une semaine les achats remontés par Meta aux commandes du back-office, en gardant en tête que les règles d’attribution diffèrent.

- Tester le parcours avec refus des cookies : aucun événement personnel ne doit partir.

- Relire la note de qualité de correspondance par événement et corriger les formats de données.

- Documenter le dispositif et prévoir un contrôle après chaque mise à jour de thème, d’application ou de tunnel.

Ce dernier point est souvent négligé. Une intégration fonctionne rarement mal dès le premier jour ; elle se dégrade silencieusement au fil des modifications du site. Notre accompagnement en [agence tracking publicitaire](https://creapreneurs.io/agence-tracking-publicitaire/) inclut donc un suivi dans la durée, et nous relions ces contrôles aux décisions de budget prises en [performance marketing](https://creapreneurs.io/agence-performance-marketing/).

## Questions fréquentes

### L’API de conversion Meta remplace-t-elle le Pixel ?

Non. Meta recommande une configuration redondante dans laquelle le Pixel et l’API envoient les mêmes événements. Le Pixel apporte le contexte du navigateur, l’API récupère les événements que le navigateur perd. La déduplication par event_id évite de compter deux fois la même conversion.

### Comment savoir si mes événements sont bien dédupliqués ?

Dans le gestionnaire d’événements, chaque événement indique s’il est reçu par le navigateur, par le serveur ou les deux, et si des doublons sont détectés. Passez une commande test et vérifiez que le même event_id et le même nom d’événement figurent côté Pixel et côté API. Meta ne déduplique que dans une fenêtre de 48 heures.

### Quelle note de qualité de correspondance viser ?

Meta exprime la qualité de correspondance des événements sur 10 et indique qu’une meilleure correspondance améliore les résultats, sans fixer de seuil universel. Plutôt qu’une note cible, visez l’envoi de tous les paramètres autorisés et correctement formatés : email et téléphone hachés, IP et user agent non hachés, fbp et fbc à jour.

### Faut-il un développeur pour installer l’API Conversions ?

Pas forcément. Sur Shopify, le canal Facebook & Instagram active l’API aux niveaux de partage Enhanced ou Maximum, et la Conversions API Gateway se configure sans code dans le gestionnaire d’événements. Un développeur devient nécessaire pour un site sur mesure, un CRM ou un conteneur GTM côté serveur.

### Peut-on envoyer des achats à Meta si le client a refusé les cookies ?

Non, pas avec des données personnelles à des fins publicitaires. L’envoi depuis un serveur ne dispense pas du consentement : il doit respecter le choix exprimé dans le bandeau cookies. Le dispositif doit donc transmettre l’état du consentement jusqu’au serveur et conditionner l’envoi à cet état.

### Combien de temps après un achat peut-on l’envoyer par l’API ?

Selon la documentation Meta, le paramètre event_time peut remonter jusqu’à 7 jours avant l’envoi. Pour optimiser les campagnes, Meta recommande toutefois de partager les événements au moment où ils se produisent, en temps réel ou par lots proches du temps réel.