L’API Conversions de Meta
L’API Conversions Meta permet d’envoyer à Meta, depuis votre serveur, votre site, votre application ou votre outil de gestion des contacts, les actions importantes réalisées par vos clients : achat, demande de devis, inscription, rendez-vous, vente conclue hors ligne. Elle complète le pixel, qui collecte ces événements dans le navigateur, et elle sert à la mesure, aux rapports et à la diffusion des campagnes de la même façon que lui. Pour que les deux ne comptent pas deux fois la même conversion, Meta recommande la déduplication par identifiant d’événement : le même event_id et le même nom d’événement côté pixel et côté serveur, reçus dans un délai de 48 heures. Les données personnelles transmises pour faire correspondre les événements (adresse e-mail, téléphone, nom) doivent être hachées en SHA-256. Côté règles, l’API ne dispense pas du consentement : la CNIL rappelle que les traceurs publicitaires nécessitent l’accord préalable de l’internaute, et que le refus doit stopper aussi les envois vers des tiers.
Mis à jour le 23 octobre 2026
Bloqueurs de publicité, navigateurs qui limitent les traceurs, refus des cookies, connexions interrompues : une partie des conversions n’est plus vue par le pixel installé dans le navigateur. L’API Conversions répond à ce problème en faisant passer l’information par un autre chemin, plus fiable : votre propre serveur.
Cette page explique ce que fait l’API, comment l’installer proprement, comment éviter les doublons et comment rester en règle. C’est devenu une étape standard de la mise en place d’une campagne Meta Ads.
Par Alexandre Montenon, consultant en publicité digitale depuis 2011
Ce que fait l’API Conversions
Concrètement, quand un visiteur envoie un formulaire ou passe une commande, votre site envoie à Meta, en plus de l’appel du pixel, un message serveur qui décrit l’événement : son nom, sa date, sa valeur, et des informations permettant de le rattacher à une personne qui a vu ou cliqué une annonce.
| Critère | Pixel (navigateur) | API Conversions (serveur) |
|---|---|---|
| Où part l’information | Du navigateur du visiteur | De votre serveur ou de votre outil |
| Sensibilité aux bloqueurs | Forte | Faible |
| Événements hors site | Non | Oui : vente conclue par téléphone, rendez-vous honoré, contrat signé |
| Mise en place | Simple | Plus technique, sauf intégrations prêtes à l’emploi |
| Consentement nécessaire | Oui | Oui, la règle ne change pas avec le chemin technique |
Le pixel reste utile : il capte des informations du navigateur que le serveur ne voit pas. La configuration recommandée combine les deux. La page sur le pixel Meta détaille son installation et les événements standard.
Les trois façons de l’installer
1. Depuis le gestionnaire d’événements
Meta propose une configuration rapide de l’API Conversions à partir d’un pixel déjà installé, sans code, depuis le gestionnaire d’événements. C’est la solution la plus simple pour démarrer, avec moins de contrôle sur les données envoyées.
2. Par une intégration de partenaire
La plupart des solutions de boutique en ligne et de nombreux outils de gestion de site proposent une intégration prête à l’emploi. Vérifiez qu’elle gère la déduplication et qu’elle respecte le choix de consentement du visiteur.
3. Par un développement sur mesure ou un serveur de balises
Votre développeur envoie les événements directement depuis le serveur, ou vous passez par un gestionnaire de balises côté serveur. C’est la solution la plus souple, qui permet aussi d’envoyer des événements venant de votre outil de gestion des contacts.
La déduplication : ne pas compter deux fois
Si le pixel et le serveur envoient chacun l’achat, Meta reçoit deux événements pour une seule commande. Sans précaution, les conversions sont gonflées, et la diffusion apprend sur de faux chiffres.
Meta recommande de faire correspondre l’identifiant d’événement du pixel (eventID) avec l’event_id envoyé par l’API, ainsi que le nom de l’événement ; les événements ne sont dédupliqués que s’ils sont reçus dans les 48 heures suivant le premier événement portant cet identifiant. Une méthode alternative, fondée sur les identifiants de navigateur (fbp) ou externes (external_id), ne fonctionne que si l’événement du navigateur arrive avant celui du serveur.
En pratique : générez un identifiant unique par événement (par exemple le numéro de commande ou un identifiant de formulaire), utilisez-le à la fois dans l’appel du pixel et dans l’envoi serveur, et gardez exactement le même nom d’événement des deux côtés.
Quels événements envoyer
Inutile d’envoyer tout ce qui se passe sur le site. Concentrez-vous sur les événements qui ont une valeur pour l’entreprise, dans l’ordre du parcours :
- Pour un site marchand : consultation de produit, ajout au panier, début de paiement, achat avec sa valeur et sa devise.
- Pour une activité de services : demande de devis ou de contact, prise de rendez-vous, puis, depuis votre outil de suivi, prospect qualifié et client signé.
- Pour un abonnement ou un logiciel : inscription, début d’essai, souscription payante.
Choisissez ensuite un seul événement comme objectif principal des campagnes : le plus proche de la valeur réelle qui arrive en volume suffisant chaque semaine. Les autres servent à l’analyse et aux audiences, pas au pilotage. Transmettez la valeur réelle des achats ou une valeur estimée des prospects quand c’est possible : elle permet de piloter sur la rentabilité et non sur le seul nombre de conversions.
Les données de correspondance
Pour rattacher un événement à une personne, l’API accepte des informations sur le client. La documentation de Meta impose de hacher en SHA-256 l’adresse e-mail, le téléphone, le prénom et le nom, recommande de hacher l’identifiant externe, et demande au contraire de ne pas hacher l’adresse IP, l’agent utilisateur du navigateur et les identifiants de clic et de navigateur fbc et fbp.
Plus les informations transmises sont nombreuses et correctes, mieux Meta rattache les conversions aux annonces. Mais n’envoyez que ce qui est nécessaire, et seulement si l’internaute y a consenti : le principe de minimisation des données s’applique.
Le gain le plus intéressant de l’API n’est souvent pas technique, il est commercial : renvoyer à Meta l’information « ce prospect est devenu client », depuis votre outil de gestion des contacts. Une campagne qui apprend à partir des clients signés, et plus seulement des formulaires envoyés, finit par chercher des personnes qui achètent, pas des personnes qui remplissent des formulaires.
Consentement et RGPD
Faire passer les données par le serveur ne change pas les règles. La CNIL rappelle que les traceurs non essentiels nécessitent le consentement, que le consentement est en général la base légale la plus appropriée pour la publicité, et qu’après un retrait du consentement l’éditeur doit cesser les opérations de lecture et d’écriture depuis son site, y compris les requêtes vers des domaines tiers.
Concrètement :
- Branchez l’envoi serveur sur le choix exprimé dans votre bandeau de consentement : si le visiteur refuse, aucun événement publicitaire ne part, ni par le pixel ni par le serveur.
- Mentionnez Meta parmi les destinataires dans votre politique de confidentialité.
- Pour les conversions hors ligne envoyées depuis votre fichier clients, vérifiez que vos clients ont été informés de cet usage et disposent d’un moyen simple de s’y opposer.
- Ne transmettez jamais de données sensibles (santé, opinions, etc.) dans les paramètres des événements.
Vérifier que tout fonctionne
- Tester les événements dans l’outil de test du gestionnaire d’événements : chaque événement doit apparaître une fois, avec les bons paramètres.
- Contrôler la déduplication : les événements reçus par les deux canaux doivent être signalés comme dédupliqués.
- Comparer avec vos chiffres : le nombre d’achats ou de demandes remontés doit être cohérent avec votre boutique ou votre outil de gestion des contacts, sur une même période.
- Tester le refus : refusez les cookies et vérifiez qu’aucun événement publicitaire ne part.
- Surveiller dans la durée : une mise à jour du site ou d’une extension peut casser l’envoi sans prévenir.
Les erreurs fréquentes
Ignorer la déduplication. Les conversions doublent, la diffusion apprend sur de faux chiffres.
Envoyer sans tenir compte du consentement. L’envoi serveur ne contourne pas la règle.
Des noms d’événements différents entre pixel et serveur : la déduplication échoue.
Envoyer des données en clair qui doivent être hachées.
Trop d’événements secondaires marqués comme conversions principales.
Ne jamais vérifier. Un envoi cassé peut passer inaperçu des semaines.
Exemple fictif : une école de langues
Pour illustrer, un cas inventé. Une école de langues reçoit ses inscriptions par un formulaire, puis les confirme par téléphone. Le pixel ne voit que les formulaires, dont une partie n’aboutit jamais. L’école installe l’API Conversions via son outil de gestion des contacts : le formulaire est envoyé par le pixel et par le serveur avec le même identifiant, puis un second événement « inscription confirmée » part du serveur quand le conseiller valide l’inscription. Le tout est conditionné au consentement. Les campagnes sont ensuite pilotées sur les inscriptions confirmées. Les éléments de cet exemple sont inventés pour l’illustration.
Pour ce type de remontée depuis un fichier clients, la page sur le CRM pour PME aide à choisir un outil qui sait dialoguer avec les plateformes publicitaires.
- L’API Conversions Meta envoie les événements depuis votre serveur ou vos outils, en complément du pixel.
- Elle rend la mesure plus fiable et permet de remonter des conversions hors ligne.
- Déduplication : même event_id et même nom d’événement côté pixel et côté serveur, dans les 48 heures.
- E-mail, téléphone, prénom et nom se transmettent hachés en SHA-256.
- Le consentement reste obligatoire : un refus doit stopper aussi les envois serveur.
Questions fréquentes sur l’API Conversions Meta
Qu’est-ce que l’API Conversions de Meta ?
C’est un moyen d’envoyer à Meta, depuis votre serveur ou vos outils, les actions de vos clients (achats, demandes, ventes hors ligne), pour la mesure et la diffusion des campagnes.
Faut-il garder le pixel avec l’API Conversions ?
Oui, la configuration recommandée combine les deux, avec une déduplication des événements envoyés par les deux canaux.
Comment éviter les doublons ?
En utilisant le même identifiant d’événement et le même nom d’événement côté pixel et côté serveur, les deux étant reçus dans un délai de 48 heures.
L’API Conversions est-elle conforme au RGPD ?
Elle peut l’être si les envois respectent le consentement de l’internaute, si les données sont limitées au nécessaire et hachées quand c’est demandé, et si les personnes sont informées.
Peut-on envoyer des ventes conclues hors ligne ?
Oui, c’est l’un des intérêts de l’API : remonter un contrat signé ou un rendez-vous honoré depuis votre outil de gestion des contacts.
Vous avez une question, un projet ? Parlons-en ensemble.
On discute ?