Vérifié le 09/09/2026

Configurer une source de conversions serveur

Parcours confirmé dans le code

Le produit expose une source entrante de conversions signées, pas un connecteur CRM nommé. Un serveur ou adaptateur doit pouvoir produire le format attendu et signer les octets exacts du message. Aucun parcours HubSpot, Salesforce, Zapier ou autre CRM spécifique n’est qualifié ici.

L’entrée se trouve dans Développeur → Conversions serveur entrantes. Elle nécessite l’accès à la surface Développeur et le droit de gérer le projet pour créer la source. Une landing publiée et son plan de mesure actif doivent accepter les événements serveur voulus. Le rattachement suit la destination ; aucun sandbox CRM n’est créé par le badge Test du projet.

Créer la source

1. Choisissez la Landing, saisissez un nom explicite puis cochez les Événements autorisés.
2. Le formulaire propose Lead, CompleteRegistration, StartTrial, Subscribe, Purchase, Refund, QualifiedLead et WonLead ; seuls ceux déclarés serveur dans le plan actif de cette landing peuvent être autorisés.
3. Cliquez sur Créer la source. Copiez immédiatement la clé publique et le secret de signature vers le stockage sécurisé du serveur émetteur. Le secret n’est affiché qu’une fois ; ne le conservez pas dans une capture publique.
4. Faites confirmer par l’opérateur l’adresse HTTPS complète du service. L’écran fournit le chemin POST /v1/conversions/<clé-publique> ; ne l’ajoutez pas arbitrairement au domaine public de la boutique.

Contrat de transport à transmettre à l’intégrateur

Le serveur signe timestamp.body en HMAC-SHA256 avec le secret de la source, où body est exactement le texte JSON envoyé. Il fournit x-growth-timestamp (secondes Unix) et x-growth-signature (64 caractères hexadécimaux minuscules). La fenêtre de signature lue est de cinq minutes autour de l’heure serveur et la taille maximale du corps est 32 768 octets.

Le JSON doit porter request_id, event_id (UUID) et event_name autorisé. Les événements Lead, CompleteRegistration, QualifiedLead et WonLead demandent un identity.lead_id valide ; Purchase et Refund demandent identity.order_id. Les propriétés et identités doivent aussi respecter le plan actif et le projet. Un corps minimal inventé sans ces références n’est pas un exemple de conversion acceptée.

Lors d’une reprise du même événement, conservez les identifiants de requête et d’événement, puis signez à nouveau avec un horodatage courant. Un 202 signifie acceptation à l’entrée, pas livraison à Meta ou au CRM final.

Vérifier le résultat et reprendre

Dans un environnement de recette maîtrisé, envoyez un événement valide associé à une référence fictive créée dans ce projet. Conservez le reçu et l’événement, puis contrôlez la destination finale. Rejouez la même requête et vérifiez qu’elle ne crée pas une seconde conversion. Testez séparément signature invalide, événement non autorisé, référence d’un autre projet et absence de consentement pour les livraisons qui en dépendent.

Dans Identités + livraisons, une destination en échec définitif peut proposer Rejouer 1×. Corrigez d’abord sa cause, saisissez un motif d’au moins huit caractères, puis contrôlez la nouvelle tentative et son résultat. Un replay de destination n’est pas une nouvelle conversion entrante. Le replay Meta dispose d’un parcours de diagnostic distinct ; ne le déclenchez pas par assimilation.

Renouvellement et révocation

Aucun bouton de rotation ou révocation de source n’est identifié dans ce formulaire. Si le secret est perdu ou doit être retiré, faites organiser la révocation de l’ancienne source et la création d’un remplacement par le référent technique. Ne considérez pas la création d’une seconde source comme la révocation de la première. La preuve attendue est le refus de l’ancien accès puis l’acceptation du nouveau, sans doublon métier.