Avant tout debug : la cause n°1 d’une 400 sur Make.com

Quand un webhook Make.com renvoie une erreur 400, mon premier réflexe n’est pas de regarder le payload. Je vérifie d’abord que le scénario est actif. Oui, c’est basique. Mais dans ma pratique, c’est l’erreur que je vois le plus souvent chez les TPE/PME.

Active le scénario et rattache le webhook

Un scénario inactif ne reçoit aucune donnée. L’expéditeur reçoit une 400 Bad Request, car Make ne peut pas traiter la requête. Le correctif prend dix secondes : ouvre le scénario, bascule le toggle en haut à droite sur « On », puis renvoie une requête test.

Re-détermine la structure des données

Autre piège classique : le bouton Re-determine data structure. Si Make ne connaît pas le schéma du payload entrant, il refuse l’interprétation. J’ai déjà passé une heure sur un webhook qui échouait en 400 simplement parce que je n’avais pas re-cliqué sur ce bouton après avoir modifié le body. Un clic, et le webhook reconnaît le JSON. Ensuite, Make sait comment mapper les champs.

Vérifie l’URL et les ports autorisés (80 ou 443)

Make n’envoie des webhooks que vers les ports 80 et 443. Si ton endpoint écoute sur un autre port, la requête part, mais elle est refusée. Le statut 400 ne vient pas de ton application : il vient de la couche réseau. Vérifie l’URL complète, le protocole https et le port avant d’incriminer le code.

400 Bad Request : le client Make envoie un payload refusé

Le code 400 signifie que la requête est mal formée. En clair : Make a envoyé quelque chose que le serveur ne comprend pas. Pour savoir quoi, il faut regarder la request réelle.

Inspecte le payload brut avec un endpoint de capture

Je branche systématiquement un endpoint de capture temporaire : webhook.site ou ngrok. Ces outils affichent le body brut, les headers et le type de contenu. Résultat immédiat : tu vois exactement ce que Make envoie. Tu compares avec ce que ton API attend. La plupart du temps, l’erreur saute aux yeux.

JSON malformé et Content-Type : deux erreurs classiques

Un JSON avec des sauts de ligne non échappés provoque une 400 systématique. Le correctif : encoder proprement les chaînes de caractères. Autre piège : le header Content-Type. S’il annonce application/json mais que le body contient du texte brut ou un champ vide, le serveur refuse. Je vérifie toujours la cohérence entre le content-type et le contenu réel du body.

Pourquoi Postman passe mais pas la production ?

Situation frustrante : le test Postman fonctionne, mais Make reçoit une 400. La raison ? Make envoie des champs vides que tu n’avais pas prévus dans ton test. La solution : journaliser les données avant l’envoi. J’ajoute un module HTTP avec une sortie de debug, ou je fais pointer le webhook vers ngrok pour capturer le payload réel. Les données de production contiennent des surprises. Mieux vaut les voir avant le serveur.

500 Internal Server Error : le serveur destinataire a planté

Une erreur 500, c’est différent. La requête est bien formée, Make l’a envoyée, mais le serveur a échoué à la traiter. Le problème n’est pas dans la configuration du webhook, il est dans l’application qui reçoit.

Journalise la requête côté endpoint

Quand j’ai une 500, je ne regarde plus Make. Je regarde les logs du serveur destinataire. L’application a-t-elle accès aux données ? La connexion à la base de données fonctionne-t-elle ? Le message d’erreur est souvent dans le corps de la réponse HTTP. Lis ce body. Il contient parfois une stack trace ou un message explicite.

Timeout, WAF et signature : les erreurs 500 invisibles dans les logs

Parfois, le serveur ne plante pas. C’est le firewall applicatif qui bloque la requête, ou le délai de réponse qui dépasse la limite de Make. Une signature invalide peut aussi déclencher une 500 avant même que le code métier soit exécuté. Mon réflexe : envoyer une requête minimale sans payload vers la même URL depuis un outil comme curl, puis comparer les réponses.

Distinguer erreur de réception et erreur d’appel

Le webhook Make ne reçoit pas les données : c’est une erreur de réception. Le scénario exécute une requête vers un API externe qui répond 500 : c’est une erreur d’appel. Les deux problèmes n’ont pas la même source. Je regarde le rapport d’exécution dans Make. L’étape qui échoue indique le vrai coupable.

Statuts HTTP : lesquels relancent une tentative ?

Make n’a pas le même comportement selon le code de statut. C’est un point que je vois souvent ignoré, et qui explique des pertes de temps ou des doublons en base.

400-407 et 409-499 : échec permanent, pas de retry

Ces codes signifient que la requête ne peut pas aboutir. Make ne relance pas. C’est le cas pour une 400 Bad Request, une 401 non autorisé ou une 404 introuvable. Inutile d’attendre une nouvelle tentative : il faut corriger ce qui échoue.

408, 429 et 5xx : temporaire, nouvelle tentative

Les erreurs temporaires déclenchent des nouvelles tentatives : 408 timeout, 429 trop de requêtes, et tous les 5xx. Si tu reçois plusieurs 500 d’affilée, le serveur est probablement instable ou l’application est en erreur. Pense à vérifier les logs avant d’ouvrir un ticket chez Make. Et si tu es confronté à une erreur quota exceeded sur Make.com, consulte mon guide dédié.

Mon arbre de décision en 5 minutes avant d’ouvrir un ticket support

Avant de contacter l’assistance de Make, je passe par trois tests rapides. Ils permettent de résoudre la majorité des problèmes de webhook.

Test 1 : l’endpoint répond-il ?

J’envoie une requête simple vers l’URL du webhook avec un corps minimal. Si je n’obtiens aucune réponse, je vérifie l’URL, le port et la disponibilité du serveur.

Test 2 : que contient la response et le body ?

Le code HTTP et le corps de la réponse me disent si le problème vient du client ou du serveur. J’analyse les deux avant de changer quoi que ce soit.

Test 3 : le webhook reçoit-il vraiment ?

Je connecte un endpoint de capture temporaire. Si Make envoie bien les données au bon format, le bug est côté application. Sinon, la configuration Make est en cause.

Cette méthode rapide évite les allers-retours inutiles avec le support. Elle te donne une réponse fiable : soit tu corriges, soit tu transmets le bon diagnostic.