Passer au contenu

Créer une campagne webhook

La création d’une campagne webhook ou l’inclusion d’un webhook dans une campagne multicanale vous permet de déclencher des actions hors application en fournissant à d’autres systèmes et applications des informations en temps réel.

Vous pouvez utiliser les webhooks pour envoyer des informations à des systèmes tels que Salesforce ou Marketo, ou à vos systèmes backend. Par exemple, vous pourriez vouloir créditer les comptes de vos clients d’une promotion après qu’ils ont effectué un événement personnalisé un certain nombre de fois.

Étape 1 : Choisissez où créer votre message

Vous ne savez pas si votre message doit être envoyé via une Campaign ou un Canvas ? Les Campaigns conviennent mieux aux campagnes de communication ciblées et ponctuelles, tandis que les Canvas sont plus adaptés aux parcours utilisateurs en plusieurs étapes.

Étapes :

  1. Allez dans Envoi de messages > Campagnes et sélectionnez Créer une campagne.
  2. Sélectionnez Webhook ou, pour les Campaigns ciblant plusieurs canaux, sélectionnez Multicanal.
  3. Donnez à votre Campaign un nom clair et explicite.
  4. (Facultatif) Ajoutez une description pour expliquer comment cette Campaign sera utilisée.
  5. Ajoutez des Teams et des tags si nécessaire.
    • Les tags facilitent la recherche de vos Campaigns et la création de rapports. Par exemple, lorsque vous utilisez le générateur de rapports, vous pouvez filtrer par tags spécifiques.
  6. Ajoutez et nommez autant de variantes que nécessaire pour votre Campaign. Vous pouvez choisir des modèles de webhook différents pour chacune des variantes ajoutées. Pour en savoir plus à ce sujet, consultez Tests multivariés et A/B.

Étapes :

  1. Créez votre Canvas à l’aide du compositeur Canvas.
  2. Après avoir configuré votre Canvas, ajoutez une étape dans le générateur Canvas. Donnez à votre étape un nom clair et significatif.
  3. Choisissez une planification d’étape et spécifiez un délai si nécessaire.
  4. Filtrez votre audience pour cette étape si nécessaire. Vous pouvez affiner davantage les destinataires de cette étape en spécifiant des segments et en ajoutant des filtres supplémentaires. Les options d’audience seront vérifiées après le délai, au moment de l’envoi des messages.
  5. Choisissez votre comportement d’avancement.
  6. Choisissez tout autre canal de communication que vous souhaitez associer à votre message.

Étape 2 : Créer votre webhook

Vous pouvez créer un nouveau webhook, partir d’un modèle existant ou utiliser l’un de nos modèles prêts à l’emploi. Ensuite, créez votre webhook dans l’onglet Composer de l’éditeur.

L’onglet Composer contient les champs suivants :

  • Langues
  • URL du webhook
  • Méthode HTTP
  • Corps de la requête

L’onglet « Composer » avec un exemple de modèle de webhook.

Langues

Vous pouvez envoyer un seul webhook à des utilisateurs répartis sur plusieurs marchés grâce aux messages multilingues. La traduction est prise en charge dans le corps de la requête et dans l’URL du webhook.

Pour localiser un webhook :

  1. Créez les langues que vous souhaitez prendre en charge dans votre espace de travail.
  2. Dans l’onglet Composer, entourez uniquement le texte à traduire avec des étiquettes de traduction. Par exemple : {% translation greeting %}Hello!{% endtranslation %}.
  3. Sélectionnez Gérer les langues, choisissez vos langues, puis ajoutez les traductions en téléversant un fichier CSV ou en utilisant l’API de traductions.
  4. Sélectionnez Utilisateur multilingue dans la liste déroulante Prévisualiser en tant qu’utilisateur pour prévisualiser chaque langue avant l’envoi.

Pour un corps de requête composé de paires clé-valeur JSON, n’étiquetez que la valeur :

{
  "message_body": "{% translation order_ready %}Your order just arrived!{% endtranslation %}"
}

Localiser l’URL

Si votre endpoint varie selon le marché, vous pouvez entourer une partie de l’URL avec des étiquettes de traduction. Laissez le protocole (https://) en dehors des étiquettes et n’y incluez pas de paramètres de requête. Pour plus de détails, consultez Localiser les URL.

Modèles de webhook

Les modèles de webhook prennent en charge les traductions enregistrées : vous pouvez donc localiser un modèle une seule fois et le réutiliser dans vos Campaigns et vos étapes du Canvas. Vous devez disposer de l’autorisation Modifier les modèles de webhook pour ajouter des langues et des traductions à un modèle. Consultez la section Modèles de webhook.

URL du webhook

L’URL du webhook, ou URL HTTP, indique votre endpoint. L’endpoint est l’emplacement vers lequel vous envoyez les informations capturées dans le webhook.

Si vous souhaitez envoyer des informations à un fournisseur, celui-ci devrait indiquer cette URL dans sa documentation API. Si vous envoyez des informations vers vos propres systèmes, vérifiez auprès de votre équipe de développement ou d’ingénierie que vous utilisez la bonne URL.

Braze n’autorise que les URL qui communiquent via les ports standard 80 (HTTP) et 443 (HTTPS).

Utiliser Liquid

Vous pouvez personnaliser les URL de vos webhooks avec Liquid. Certains endpoints peuvent exiger que vous identifiiez un utilisateur ou que vous fournissiez des informations propres à l’utilisateur dans l’URL. Lorsque vous utilisez Liquid, veillez à inclure une valeur par défaut pour chaque information propre à l’utilisateur utilisée dans votre URL.

Méthode HTTP

La méthode HTTP à utiliser dépend de l’endpoint auquel vous envoyez les informations. Dans la plupart des cas, vous utiliserez POST.

Méthode HTTP Description
POST Écrit de nouvelles informations sur le serveur destinataire. C’est la méthode la plus courante pour envoyer des données.
GET Récupère des informations existantes, au lieu d’en écrire de nouvelles. Par définition, une requête GET ne prend pas en charge de corps de requête.
PUT Met à jour les informations sur l’endpoint en remplaçant les informations existantes par le contenu du corps de la requête.
DELETE Supprime la ressource indiquée dans l’URL HTTP.

Corps de la requête

Le corps de la requête correspond aux informations envoyées à l’URL que vous avez indiquée. Vous pouvez créer le corps de votre requête webhook avec des paires clé-valeur JSON ou du texte brut.

Paires clé-valeur JSON

Les paires clé-valeur JSON vous permettent de rédiger facilement une requête pour un endpoint qui attend un format JSON. Cette option ne fonctionne qu’avec un endpoint qui attend une requête JSON. Par exemple, si votre clé est message_body, la valeur correspondante pourrait être Your order just arrived!. Une fois votre paire clé-valeur saisie, le compositeur configure votre requête en syntaxe JSON et un aperçu de votre requête JSON s’affiche automatiquement.

Corps de la requête défini sur des paires clé-valeur JSON.

Vous pouvez personnaliser vos paires clé-valeur avec Liquid, par exemple en incluant n’importe quel attribut utilisateur, attribut personnalisé ou propriété d’événement dans votre requête. Vous pouvez ainsi inclure le prénom et l’adresse e-mail d’un client. Veillez à inclure une valeur par défaut pour chaque attribut.

Texte brut

L’option texte brut vous offre la flexibilité de rédiger une requête pour un endpoint qui attend un corps dans n’importe quel format. Vous pouvez par exemple l’utiliser pour rédiger une requête destinée à un endpoint qui attend une requête au format XML.

La personnalisation et les étiquettes de traduction sont toutes deux prises en charge dans le texte brut.

Exemple de corps de requête en texte brut utilisant Liquid.

Si vous définissez l’en-tête de requête Content-Type sur application/x-www-form-url-encoded, le corps de la requête doit être formaté sous forme de chaîne de caractères encodée en URL. Par exemple :

to={{custom_attribute.${example}}}&text=Your+order+just+arrived

Corps de la requête avec une chaîne de caractères encodée en URL.

Étape 3 : Configurer des paramètres supplémentaires

Utiliser un identifiant enregistré (facultatif)

Utilisez un identifiant enregistré pour authentifier un webhook sans saisir son mot de passe ou son jeton dans le message. Vous pouvez réutiliser les identifiants d’authentification de base et d’authentification par jeton depuis Paramètres > Gestion des identifiants dans vos campagnes webhook, vos étapes de Canvas et vos modèles de webhook.

Chaque identifiant appartient à un seul espace de travail. Créez un identifiant dans chaque espace de travail où vous en avez besoin, y compris dans des espaces de travail distincts de développement, de staging et de production.

Pour sélectionner un identifiant existant, vous avez besoin de l’autorisation « Manage App Group » ou de l’autorisation de modification correspondante : « Edit Campaigns », « Edit Canvases » ou « Edit Webhook Templates ». Pour créer, modifier ou supprimer des identifiants, vous avez besoin de l’autorisation « Manage App Group ». Si nécessaire, demandez à l’administrateur de votre espace de travail de vous l’accorder.

  1. Dans l’onglet Composer, saisissez une URL de webhook HTTPS avec un nom d’hôte fixe, par exemple https://api.example.com/events. Vous pouvez utiliser Liquid dans le chemin ou les paramètres de requête, mais le nom d’hôte doit être statique pour pouvoir sélectionner un identifiant.
  2. Dans Identifiant, sélectionnez un identifiant enregistré. La liste affiche les identifiants dont le domaine autorisé correspond au nom d’hôte de l’URL, y compris ceux qui autorisent un domaine parent.
  3. Si vous êtes autorisé à créer des identifiants, sélectionnez Ajouter un identifiant dans le sélecteur pour en créer un. Sélectionnez Authentification de base ou Authentification par jeton, saisissez un nom d’identifiant unique et les informations d’authentification, puis sélectionnez Ajouter un identifiant. Le domaine autorisé est renseigné à partir du nom d’hôte du webhook et ne peut pas être modifié dans ce formulaire.
  4. Vérifiez l’identifiant sélectionné avant d’enregistrer ou d’envoyer un webhook de test.

Si votre nom d’hôte provient de Liquid ou d’un bloc de contenu, gérez l’authentification dans les en-têtes de requête. Pour utiliser un identifiant enregistré, modifiez l’URL afin qu’elle utilise un nom d’hôte fixe et placez les valeurs dynamiques dans le chemin ou les paramètres de requête.

Les deux types d’identifiants nécessitent un domaine autorisé pour être utilisés avec des webhooks. Un identifiant d’authentification de base sans domaine reste utilisable pour le contenu connecté, mais il n’apparaît pas dans le sélecteur du webhook. Consultez la colonne Disponible dans de la page Gestion des identifiants pour vérifier si un identifiant prend en charge les webhooks. Pour des exemples de configuration et de domaines, consultez Types d’authentification.

Braze applique l’authentification enregistrée lors de l’envoi de la requête. L’authentification de base fournit l’en-tête Authorization. L’authentification par jeton fournit les en-têtes enregistrés dans l’identifiant. Si vous saisissez manuellement un en-tête portant le même nom, la valeur de l’identifiant enregistré est prioritaire. Les noms d’en-têtes ne sont pas sensibles à la casse.

Si vous modifiez l’URL de sorte que l’identifiant sélectionné ne correspond plus, le compositeur efface la sélection. Sélectionnez à nouveau un identifiant correspondant avant d’enregistrer. Braze valide également l’identifiant et l’URL de destination générée au moment de l’envoi. Un identifiant non valide ou une destination non autorisée empêche l’envoi du webhook.

Pour mettre à jour ou supprimer un identifiant enregistré, consultez Gérer les identifiants enregistrés.

Prévisualiser les identifiants enregistrés

L’aperçu du webhook affiche l’URL générée, le corps et les en-têtes de requête saisis manuellement. Il n’affiche ni la référence à l’identifiant sélectionné ni les en-têtes d’authentification fournis par cet identifiant, plutôt que de montrer des valeurs masquées. Braze applique l’identifiant enregistré lors de l’envoi d’un webhook de test ou en production.

Dans le compositeur, les utilisateurs qui ne disposent pas de l’autorisation « Manage App Group » ou de l’autorisation de modification correspondante voient Masqué dans le sélecteur Identifiant désactivé lorsqu’un identifiant est sélectionné. Ils ne peuvent ni consulter ni modifier la sélection.

En-têtes de requête (facultatif)

Certains endpoints peuvent exiger que vous incluiez des en-têtes dans votre requête. Dans la section Composer du compositeur, vous pouvez ajouter autant d’en-têtes que nécessaire.

Exemples d’en-têtes de requête pour la clé « Authorization » et la clé « Content-type ».

Les en-têtes de requête les plus courants sont les spécifications Content-Type (qui décrivent le type de données attendu dans le corps, comme XML ou JSON) et les en-têtes Authorization, qui contiennent vos identifiants auprès de votre fournisseur ou de votre système.

Les spécifications de type de contenu doivent utiliser la clé Content-Type. Les valeurs courantes sont application/json ou application/x-www-form-urlencoded.

Les en-têtes d’autorisation doivent utiliser la clé Authorization. Les valeurs courantes sont Bearer {{YOUR_TOKEN}} ou Basic {{YOUR_TOKEN}} , où YOUR_TOKEN correspond aux identifiants fournis par votre fournisseur ou votre système.

Étape 4 : Tester l’envoi de votre message

Avant de mettre votre campagne en ligne, Braze vous recommande de tester le webhook pour vous assurer que la requête est correctement formatée. Si vous avez sélectionné un identifiant enregistré, l’envoi de test l’utilise pour authentifier la requête.

Pour ce faire, passez à l’onglet Test et envoyez un webhook de test. Vous pouvez tester le webhook en tant qu’utilisateur aléatoire, en tant qu’utilisateur spécifique (en saisissant son adresse e-mail ou son ID d’utilisateur externe), ou en tant qu’utilisateur personnalisé avec les attributs de votre choix.

Après l’envoi du webhook de test, une boîte de dialogue s’affiche avec le message de réponse. Si la requête webhook échoue, consultez le message d’erreur pour vous aider à résoudre les problèmes de votre webhook. L’exemple suivant présente la réponse d’un webhook dont l’URL est invalide.

404 Not Found

{
  "error": {
    "message": "Unrecognized request URL. Please see https://lob.com/docs or email us at [email protected].",
    "status_code": 404
  }
}

Pour plus d’informations, consultez Envoyer des messages de test.

Étape 5 : Créer le reste de votre Campaign ou Canvas

Ensuite, créez le reste de votre Campaign. Consultez les sections suivantes pour savoir comment tirer le meilleur parti de nos outils pour créer des webhooks.

Choisir la planification ou le déclencheur de livraison

Les webhooks peuvent être livrés à une heure planifiée, à la suite d’une action ou via un déclencheur API. Pour en savoir plus, consultez la section Planifier votre Campaign.

Pour la livraison par événement, vous pouvez également définir la durée de la Campaign et les heures calmes.

C’est également à cette étape que vous pouvez définir les contrôles de livraison, par exemple permettre aux utilisateurs de redevenir éligibles pour recevoir la Campaign, ou activer des règles de limite de fréquence.

Choisir les utilisateurs à cibler

Ensuite, vous devez cibler des utilisateurs en choisissant des Segments ou des filtres pour affiner votre audience. À cette étape, vous sélectionnez l’audience globale à partir de vos Segments, puis vous pouvez affiner davantage ce Segment avec nos filtres si vous le souhaitez. Vous obtenez automatiquement un aperçu de la population approximative de ce Segment. Gardez à l’esprit que l’appartenance exacte à un Segment est toujours calculée juste avant l’envoi du message.

Choisir les événements de conversion

Braze vous permet de suivre la fréquence à laquelle les utilisateurs effectuent des actions spécifiques, appelées événements de conversion, après avoir reçu une Campaign. Vous pouvez définir une fenêtre allant jusqu’à 30 jours pendant laquelle une conversion est comptabilisée si l’utilisateur effectue l’action spécifiée.

Si ce n’est pas déjà fait, complétez les sections restantes de votre étape du canvas. Pour en savoir plus sur la création du reste de votre Canvas, notamment les tests multivariés et la fonctionnalité Optimiser avec BrazeAITM, consultez la section Créer votre Canvas.

Étape 6 : Vérifier et déployer

Une fois la dernière étape de votre Campaign ou de votre Canvas terminée, vérifiez-en les détails, testez-le, puis envoyez-le !

Ce qu’il faut savoir

Erreurs, logique de nouvelle tentative et délais d’expiration

Les webhooks reposent sur des requêtes envoyées par les serveurs de Braze vers un endpoint externe, et des erreurs peuvent parfois survenir. Les plus courantes sont les erreurs de syntaxe, les clés API expirées, les limites de débit et les problèmes inattendus côté serveur. Avant d’envoyer une campagne webhook :

  • Testez votre webhook pour détecter les erreurs de syntaxe
  • Assurez-vous que les variables personnalisées ont des valeurs par défaut

Si l’envoi de votre webhook échoue, un message d’erreur est enregistré dans le journal d’activité des messages. Il indique notamment l’horodatage de l’erreur, le nom de l’application et des détails sur l’erreur.

Erreur de webhook avec le message « An active access token must be used to query information about the current user ».

Si le message d’erreur ne permet pas d’identifier clairement sa source, consultez la documentation de l’endpoint API que vous utilisez. Elle explique généralement les codes d’erreur utilisés par l’endpoint ainsi que leurs causes habituelles.

Codes de réponse et logique de nouvelle tentative

Lorsque la requête webhook est envoyée, le serveur destinataire renvoie un code de réponse indiquant ce qu’il est advenu de la requête. Le tableau suivant résume les différentes réponses que le serveur peut envoyer, leur impact sur l’analyse des campagnes et si, en cas d’erreur, Braze tentera de renvoyer la campagne :

Code de réponse Marqué comme reçu ? Nouvelles tentatives ?
20x (succès) Oui S.O.
30x (redirection) Non Non
408 (délai de requête expiré) Non Oui
429 (débit limité) Non Oui
Other 4XX (erreur client) Non Non
5XX (erreur serveur) Non Oui

Les en-têtes de réponse Retry-After et de limite de débit peuvent influer sur le temps d’attente de Braze avant une tentative éligible à une nouvelle tentative (par exemple, après une réponse 408, 429 ou 5XX). Ils ne rendent pas éligibles à une nouvelle tentative les réponses qui ne le sont pas, comme 401.

403 Forbidden et liste d’adresses IP autorisées {#403-forbidden-and-ip-allowlisting} {#403-forbidden-and-ip-allowlisting}

Une réponse 403 Forbidden signifie que votre endpoint a bien reçu la requête, mais l’a refusée. Les causes courantes sont une authentification invalide ou manquante, des autorisations API insuffisantes et des règles réseau (comme un pare-feu ou un pare-feu d’application web) qui bloquent les adresses IP sortantes de Braze.

Si les requêtes webhook renvoient systématiquement 403 alors que vos en-têtes d’authentification sont corrects, ajoutez les adresses IP de Braze correspondant à votre cluster à la liste d’autorisation du serveur qui reçoit le webhook. Consultez Liste d’adresses IP autorisées. Les requêtes de contenu connecté utilisent les mêmes adresses IP sortantes ; consultez Liste d’adresses IP autorisées pour le contenu connecté.

Pour d’autres étapes de résolution des problèmes liés aux erreurs 4XX, consultez Résolution des problèmes liés aux requêtes webhook et de contenu connecté.

Authentification et identifiants de contenu connecté

Sélectionnez un identifiant dans le générateur de webhook pour authentifier la requête sortante. Sur cette page, consultez Utiliser un identifiant enregistré.

Les options Liquid :basic_auth et :auth_credentials authentifient uniquement l’appel {% connected_content %} dans lequel elles figurent. Elles ne sélectionnent pas d’identifiant pour la requête webhook principale. Pour récupérer un jeton ou un secret au moment de l’envoi, vous pouvez placer une étiquette {% connected_content %} dans un champ d’en-tête ou de corps afin que Liquid la résolve avant l’envoi du webhook.

Modèles de webhook enregistrés et utilisation dans les campagnes

Braze ne propose pas de rapport intégré répertoriant chaque campagne ou étape du canvas qui fait référence à un modèle de webhook enregistré donné. Pour auditer son utilisation, passez en revue les étapes webhook qui utilisent la même URL et la même méthode HTTP, ou contactez l’assistance Braze.

Résolution des problèmes et détails supplémentaires sur les erreurs

Pour des explications détaillées, des étapes de résolution des problèmes et des conseils pour corriger des erreurs de webhook spécifiques, consultez Résolution des problèmes liés aux requêtes webhook et de contenu connecté. Vous y trouverez également des explications sur le fonctionnement de notre système de détection des hôtes défaillants et sur la manière dont Braze fournit des notifications d’erreur par e-mails automatisés et via une journalisation supplémentaire dans Braze Currents.

Liste d’adresses IP autorisées

Lorsqu’un webhook est envoyé depuis Braze, les serveurs de Braze effectuent des requêtes réseau vers les serveurs de nos clients ou de tiers. La liste d’adresses IP autorisées vous permet de vérifier que les requêtes webhook proviennent bien de Braze, ce qui ajoute une couche de sécurité.

Braze enverra les webhooks depuis les adresses IP suivantes. Les adresses IP répertoriées sont automatiquement et dynamiquement ajoutées à toutes les clés API pour lesquelles la liste d’autorisation a été activée.

Pour les instances US-01, US-02, US-03, US-04, US-05, US-06, US-07, voici les adresses IP correspondantes :

  • 23.21.118.191
  • 34.206.23.173
  • 50.16.249.9
  • 52.4.160.214
  • 54.87.8.34
  • 54.156.35.251
  • 52.54.89.238
  • 18.205.178.15

Pour l’instance US-08, voici les adresses IP correspondantes :

  • 52.151.246.51
  • 52.170.163.182
  • 40.76.166.157
  • 40.76.166.170
  • 40.76.166.167
  • 40.76.166.161
  • 40.76.166.156
  • 40.76.166.166
  • 40.76.166.160
  • 40.88.51.74
  • 52.154.67.17
  • 40.76.166.80
  • 40.76.166.84
  • 40.76.166.85
  • 40.76.166.81
  • 40.76.166.71
  • 40.76.166.144
  • 40.76.166.145

Pour l’instance US-10, voici les adresses IP correspondantes :

  • 100.25.232.164
  • 35.168.86.179
  • 52.7.44.117
  • 3.92.153.18
  • 35.172.3.129
  • 50.19.162.19

Pour les instances EU-01 et EU-02, voici les adresses IP correspondantes :

  • 52.58.142.242
  • 52.29.193.121
  • 35.158.29.228
  • 18.157.135.97
  • 3.123.166.46
  • 3.64.27.36
  • 3.65.88.25
  • 3.68.144.188
  • 3.70.107.88

Pour l’instance AU-01, voici les adresses IP correspondantes :

  • 13.210.1.145
  • 13.211.70.159
  • 13.238.45.54
  • 52.65.73.167
  • 54.153.242.239
  • 54.206.45.213

Pour l’instance ID-01, voici les adresses IP correspondantes :

  • 108.136.157.246
  • 108.137.30.207
  • 16.78.128.71
  • 16.78.14.134
  • 16.78.162.208
  • 43.218.73.35

Pour l’instance JP-01, voici les adresses IP correspondantes :

  • 13.159.155.212
  • 54.199.221.241
  • 13.192.23.16
  • 54.250.120.139
  • 18.181.114.232
  • 3.114.38.100

Pour l’instance KR-01, voici les adresses IP correspondantes :

  • 43.200.215.4
  • 52.79.67.175
  • 52.79.113.60
  • 3.34.212.92
  • 54.116.134.231
  • 3.37.197.225

Supprimer des utilisateurs

Pour supprimer un utilisateur individuel ou un segment d’utilisateurs, accédez à Audience > Gérer l’audience > Supprimer des utilisateurs. Le tableau de bord prend en charge la suppression groupée par segment (jusqu’à 25 millions de profils), inclut une période d’annulation de 7 jours et ne consomme pas les limites de débit partagées de la REST API. Pour connaître les étapes, les limites et les autorisations, consultez Supprimer des utilisateurs.

Pour une suppression programmatique par lots plus petits, utilisez l’endpoint /users/delete plutôt qu’une campagne webhook.

New Stuff!