Utiliser l'action Webhook personnalisé (pour envoyer des requêtes HTTP avancées à vos API externes)

L'action Webhook personnalisé vous permet d'envoyer des données en temps réel vers un service externe directement depuis vos automatisations, à l'aide de requêtes GET, POST, PUT et DELETE. Vous configurez l'authentification, les en-têtes, les paramètres et le corps de la requête (avec des valeurs dynamiques), sans écrire une ligne de code. C'est l'outil idéal pour connecter CrocoClick à un CRM tiers, une application métier ou une API sur mesure.

Qu'est-ce que le Webhook personnalisé ?

Tarif client standard à l’usage : 0,025 USD par exécution premium facturable (référence du 5 novembre 2026), hors option incluant des usages. Un prix contractuel ou un réglage propre à votre compte peut primer : vérifiez les conditions applicables dans votre facturation avant activation. Ce montant ne comprend pas automatiquement les coûts d’une API externe, d’un modèle IA ou d’un service de communication.

Le Webhook personnalisé est une action sortante : quand une automatisation atteint cette étape, CrocoClick assemble vos en-têtes, vos paramètres et votre payload (y compris les valeurs dynamiques mappées) puis envoie la requête HTTP vers l'URL que vous avez choisie.

Le Webhook personnalisé propose davantage de contrôles que le Webhook sortant simple : méthode, type de contenu, corps et autorisation. Choisissez les options compatibles avec le contrat de l’API et celles effectivement disponibles dans votre compte.

Pourquoi utiliser le Webhook personnalisé ?

• Des méthodes flexibles : choisissez la méthode requise par votre API parmi celles proposées, notamment GET, POST, PUT et DELETE. La capture montre aussi PATCH, HEAD et OPTIONS ; leur disponibilité ne rend pas tous les contrats d’API compatibles automatiquement.
• Plusieurs modes d'authentification : jeton Bearer, clé API, authentification Basic, OAuth2 ou aucune authentification avec en-têtes personnalisés.
• Un mapping de données précis : les valeurs dynamiques (par exemple {{contact.email}}) alimentent les en-têtes, les paramètres ou le corps, pour que chaque appel contienne les bonnes informations du contact.
• Des schémas réutilisables : construisez une fois, réutilisez partout avec des en-têtes, des types de contenu et des payloads cohérents.
• Un dépannage plus rapide : la capture optionnelle de la réponse et les journaux d'exécution facilitent les tests et la résolution des problèmes.

Webhook personnalisé ou Webhook sortant : lequel choisir ?

Les options d'authentification

Choisissez l’authentification prise en charge par l’API. Utilisez les champs prévus et privilégiez les en-têtes pour les secrets ; une clé dans l’URL ne doit être employée que si le fournisseur l’exige et après vérification de l’exposition dans les journaux.

• Jeton Bearer : ajoute l'en-tête Authorization: Bearer <jeton>. Exemple : Authorization: Bearer JETON_FOURNISSEUR.
• Clé API : la plupart des services attendent un en-tête personnalisé (par exemple X-API-Key: <clé>). Exemple : X-API-Key: CLE_API_FOURNISSEUR. N'utilisez une clé en paramètre d'URL (?api_key=...) que si le fournisseur l'exige.
• Authentification Basic : renseignez le nom d'utilisateur et le mot de passe dans les champs d'autorisation. CrocoClick envoie l'en-tête Authorization: Basic ... correct.
• OAuth2 : configurez d'abord le jeton dans les paramètres globaux de l'automatisation (OAuth2 / Gestion des jetons), puis sélectionnez-le dans l'action. Recommandé pour les fournisseurs qui renouvellent automatiquement leurs jetons.
• Aucune authentification + en-tête personnalisé : si le fournisseur exige un en-tête de clé spécifique, choisissez l’option adaptée et renseignez cet en-tête. Une signature calculée à partir du corps de requête n’est pas une simple clé statique ; suivez le mécanisme documenté par l’API.

Les méthodes HTTP et les composants de la requête

Associer la bonne méthode et placer la donnée au bon endroit de la requête évite les erreurs 400, 401 ou 422 et accélère vos intégrations.

• URL et paramètres de chemin : vous pouvez insérer des variables dans le chemin, par exemple https://api.example.com/contacts/{{contact.id}}.
• GET : récupère des données. Le corps est généralement ignoré, utilisez des paramètres de requête : https://api.example.com/leads?email={{contact.email}}&status=active.
• POST : crée une ressource. Envoyez un corps JSON ou des données de formulaire (selon le Content-Type).
• PUT : met à jour une ressource. Nécessite en général un identifiant dans le chemin et un corps JSON.
• DELETE : supprime une ressource. Inclut souvent l'identifiant dans le chemin.
• Content-Type : valeurs courantes application/json (corps JSON) ou application/x-www-form-urlencoded (champs de formulaire). Respectez la documentation de votre fournisseur.

Le mode Event (comportement de l'interface)

L'action propose deux modes de configuration. Le champ Event contrôle les champs affichés.

• Event = CUSTOM (avancé) : affiche le sélecteur de méthode (GET, POST, PUT, DELETE), le Content-Type et un éditeur de corps brut pour le JSON ou d'autres formats. À privilégier pour les payloads JSON, les méthodes autres que POST, ou des en-têtes et types de contenu explicites.
• Event = POST (simple) : affiche un corps sous forme de paires Clé et Valeur pour un envoi de type formulaire, sans éditeur de corps brut. Idéal pour des soumissions clé/valeur simples. Passez en CUSTOM si votre fournisseur attend du JSON.
• Event = GET (simple) : pas de corps de requête. Utilisez les paramètres de requête pour vos filtres. L'option d'enregistrement de la réponse est disponible.

En-têtes et paramètres de requête

Les API exigent souvent des en-têtes et des paramètres précis pour l'authentification, le type de contenu, la version ou le filtrage. Mappez des valeurs dynamiques quand c'est nécessaire.

Exemples d'en-têtes :

Authorization: Bearer JETON_FOURNISSEURContent-Type: application/jsonX-API-Key: CLE_API_FOURNISSEURX-App-Version: 2024-11-01

Exemples de paramètres de requête :

lead_id={{contact.id}}email={{contact.email}}source=workflow

Payload et mapping des champs

Les valeurs dynamiques personnalisent chaque requête avec les données du contact, de l'opportunité ou de l'automatisation, dans le format attendu par l'API externe.

Payload JSON à plat (POST / création) :

{
  "id": "{{contact.id}}",
  "first_name": "{{contact.first_name}}",
  "last_name": "{{contact.last_name}}",
  "email": "{{contact.email}}",
  "phone": "{{contact.phone}}"
}

JSON imbriqué :

{
  "contact": {
    "id": "{{contact.id}}",
    "name": "{{contact.name}}",
    "phones": [
      "{{contact.phone}}"
    ],
    "tags": [
      "new-lead"
    ]
  }
}

Format formulaire : réglez le Content-Type sur application/x-www-form-urlencoded et fournissez des paires clé/valeur au lieu du JSON.

Comment configurer l'action Webhook personnalisé

1. Ouvrez votre automatisation

Rendez-vous dans Automatisation, puis ouvrez l'automatisation où vous souhaitez envoyer des données, afin que l'exécution atteigne cette action avec le bon contexte de contact.

2. Ajoutez l'action

Cliquez sur + Ajouter une action, puis Envoyer des données, puis Webhook personnalisé pour ajouter l’étape d’appel HTTP sortant.

La capture repère le catalogue, sans requête exécutée.

3. Nommez l'action

Donnez un nom clair et descriptif pour faciliter la lecture et le dépannage plus tard, par exemple Envoyer le lead vers le CRM externe.

4. Sélectionnez l'Event (et la méthode si nécessaire)

Choisissez l'Event correspondant à votre cas. CUSTOM révèle le sélecteur de méthode, le Content-Type et l'éditeur de corps brut. POST propose une interface simple de paires clé/valeur. GET n'a pas de corps.

5. Saisissez l'URL

Collez l'URL de votre fournisseur et insérez des variables dans le chemin si besoin, comme https://api.example.com/leads/{{contact.id}}, pour que chaque requête cible le bon enregistrement.

6. Choisissez l'autorisation

Sélectionnez la méthode d'authentification requise (Bearer, Clé API, Basic, OAuth2 ou Aucune avec en-têtes personnalisés) et renseignez les identifiants exactement comme indiqué pour éviter les erreurs 401/403.

7. Ajoutez les en-têtes et les paramètres (si besoin)

Renseignez les en-têtes requis comme Content-Type et Authorization, ainsi que les paramètres de requête pour les filtres GET. Les valeurs dynamiques telles que email={{contact.email}} personnalisent chaque appel.

8. Enregistrez la réponse du Webhook (optionnel)

Activez la capture de la réponse si elle est disponible sur votre compte, pour faciliter le dépannage et l'archivage.

9. Enregistrez et testez

Enregistrez l’action et testez avec des données fictives sur un endpoint autorisé. Contrôlez les journaux du workflow et du fournisseur, puis vérifiez l’effet métier et le contenu de la réponse.

Tester et dépanner

Valider vos requêtes avant la mise en ligne évite les automatisations cassées. Combinez les outils du fournisseur et les journaux de l'automatisation.

• Utilisez un contact de démonstration et un endpoint de test que vous contrôlez. Un test de workflow peut appeler réellement l’API : ne choisissez pas une URL de paiement, d’envoi client ou de suppression en production.
• Pour inspecter une requête, utilisez un endpoint de diagnostic autorisé avec des données fictives et sans secret de production. Vérifiez la méthode, les en-têtes expurgés, les paramètres et les types du corps.
• Vérifiez d'abord les bases : URL correcte, méthode, Content-Type, en-têtes requis et identifiants valides.
• Consultez les journaux d'exécution pour confirmer que l'action s'est déclenchée et vérifier les codes de statut.
• Si le Content-Type ou l'éditeur de corps brut n'apparaissent pas, vérifiez le champ Event. Choisissez CUSTOM pour un payload JSON ou une requête PUT/DELETE.

Codes HTTP courants :

Foire aux questions

Contrôler la réponse métier

Un code 200 ou 201 confirme une réponse HTTP réussie ; vérifiez aussi le contenu retourné et l’enregistrement réellement créé ou modifié. Un code 202 peut signifier que le travail est seulement accepté pour traitement.

1. Activez la conservation de la réponse si elle est proposée, puis exécutez un cas de démonstration.
2. Comparez l’identifiant, le statut métier et les champs retournés avec le résultat attendu côté fournisseur.
3. Référencez la sortie de cette action dans une condition suivante lorsque le sélecteur l’expose. Si le traitement est asynchrone, attendez son événement de fin ou contrôlez son statut selon le contrat de l’API.
4. Testez une donnée invalide et un jeton refusé pour vérifier la branche ou le traitement d’échec.
5. Avant toute relance d’une création après erreur ou délai d’attente, recherchez si elle a déjà eu lieu ou utilisez le mécanisme d’idempotence du fournisseur.

Dans les exemples, JETON_FOURNISSEUR et CLE_API_FOURNISSEUR sont des repères explicatifs. Renseignez les identifiants dans les champs d’authentification prévus ; ce ne sont pas des variables natives CrocoClick.