Erreur webhook Make : comment débugger une 400 ou 500 ?

Vous êtes en plein debug d’une erreur webhook sur Make.com ? Vous venez de recevoir un statut 400 ou 500, et votre scénario reste bloqué en rouge. Je connais cette situation. Dans ma pratique, je vois des dirigeants perdre une après-midi sur une cause finalement simple. Voici ma méthode de terrain pour diagnostiquer et corriger ces deux codes HTTP, avec des réflexes concrets.

Comprendre l’erreur webhook Make en 30 secondes

Pourquoi Make renvoie une 400 Bad Request ou une 500 Internal Server Error

Une 400 Bad Request est un problème côté client. Make envoie une requête HTTP que le serveur destinataire refuse. Le body est peut-être mal formé, ou un champ obligatoire manque. Une 500 Internal Server Error est un problème côté serveur. L’application destinataire a reçu le call, mais elle a planté. Pour un webhook Make.com, la 500 signifie que votre endpoint a un bug, pas que Make est en cause.

Ce que Make ne vous dit pas dans les logs : la vraie cause est souvent ailleurs

Dans les logs Make, vous voyez simplement “error” avec le code HTTP. Le message dans la response est souvent absent. La config du webhook n’apparaît pas. Il faut donc aller chercher la vraie cause dans le serveur récepteur. Mon premier réflexe : ne jamais rester sur l’interface Make. J’ouvre les logs applicatifs de l’API.

La règle des retries Make : 400 = échec permanent, 500 = nouvelle tentative

Ce point est décisif. Make ne relance pas les requêtes pour les erreurs 400 à 407, ni pour les codes 409 à 499. Ce sont des échecs permanents. En revanche, les statuts 408, 429 et tous les 5xx déclenchent un retry automatique. Pour une 500, votre serveur peut recevoir plusieurs appels identiques. Pour une 400, Make abandonne immédiatement.

Checklist de debug pour une 400 Bad Request

Vérifier que le scénario est actif : cause n°1 d’une 400

C’est bête. Mais c’est l’erreur la plus fréquente que je croise. Si le scénario Make est inactif, le webhook répond 400 Bad Request immédiatement. Le module n’écoute plus. Vérifiez le toggle en haut du scénario. Ensuite, relancez un test.

Utiliser le bouton « Re-determine data structure » après chaque modification

Quand vous modifiez le payload dans un module précédent, l’ancien schéma reste en cache. Le webhook continue d’envoyer un body incohérent. Cliquez sur « Re-determine data structure ». Ce bouton force Make à recalculer la structure de données attendue. Sans lui, vous aurez des 400 même avec un JSON valide.

Contrôler l’URL : protocole https, ports 80/443, zéro faute de frappe

Le webhook ne fonctionne qu’en HTTPS, sur les ports 80 et 443. Si votre endpoint utilise un autre port, Make renvoie le message “Allowed ports are 443 and 80”. Vérifiez aussi qu’il n’y a pas de faute de frappe dans l’URL. Un copier-coller avec un espace invisible suffit à casser le call.

Inspecter le payload brut avec webhook.site ou ngrok

Pour voir ce que Make envoie réellement, utilisez un endpoint de capture. webhook.site génère une URL unique qui affiche le body, les headers et la méthode POST. Remplacez temporairement l’URL de votre webhook par celle-ci, puis déclenchez le scénario. Vous verrez le JSON brut, le Content-Type, et la structure exacte. Comparez avec ce que votre application attend.

Debugger une 500 quand le serveur ne répond pas

Journaliser la requête et la réponse côté endpoint

Pour une 500, le problème vient de votre application. Activez les logs dans le serveur qui reçoit le request. Notez la date, le body reçu, et la pile d’exécution. Un script PHP, une application Node.js ou un back-end Java produisent tous une trace exploitable. Vous verrez rapidement si c’est une variable non définie, un appel externe en timeout, ou un bug de logique.

Vérifier timeouts, WAF, certificat SSL/TLS et signature invalide

Une 500 silencieuse a plusieurs causes possibles. Le serveur peut mettre trop de temps à répondre : le WAF coupe la connexion. Un certificat SSL/TLS expiré bloque le handshake. Une signature HMAC invalide fait rejeter la requête par votre API. Testez d’abord votre endpoint avec un simple curl en HTTPS. Si le curl passe, le problème vient d’une différence d’environnement ou d’un proxy.

Le piège des retries Make : traiter la cause racine avant la 4e tentative

Make relance automatiquement sur les 5xx. Si vous voyez plusieurs requêtes identiques dans vos logs, c’est ce mécanisme de retry. Il surcharge inutilement votre serveur. Traitez la cause racine rapidement. Si vous ne pouvez pas corriger dans la minute, désactivez le scénario pour stopper les appels répétés.

Le cas « Postman passe, mais pas Make »

Comparer les headers, le Content-Type et le format exact du JSON

C’est le scénario classique. Sous Postman, tout fonctionne. Dans Make, le webhook échoue en 400. La différence se joue dans les headers. Make peut envoyer un Content-Type légèrement différent, ou un header supplémentaire. Ouvrez les logs de votre serveur et comparez les deux requêtes. Le body doit être strictement identique. Un champ manquant ou un type de champ différent suffit.

Le piège du JSON malformé : sauts de ligne non échappés

Un JSON avec des retours à la ligne non échappés provoque une 400 systématique. Vérifiez que le body est valide avec un validateur JSON en ligne. Si vous construisez le payload dans un module Make, assurez-vous d’utiliser le bon type de données. Les objets et tableaux doivent être structurés, pas concaténés sous forme de texte.

Environnement réseau, reverse proxy et variables de production

Le staging passe, la production échoue. C’est souvent un reverse proxy qui modifie les headers, ou une variable d’environnement absente. Comparez les configurations entre les deux environnements. Un pare-feu peut aussi bloquer le port entrant. Dans ce cas, l’erreur HTTP peut être une 500 ou un timeout. Vérifiez les règles réseau et les certificats.

Méthode de test complète en production

Activer le webhook, envoyer une requête test, capturer le payload

Avant de modifier quoi que ce soit, activez le scénario. Ensuite, envoyez une requête test depuis Make. Utilisez un endpoint de capture pour voir le payload brut. Cette étape prend deux minutes. Elle vous évite de supposer que Make envoie ce que vous croyez.

Re-déterminer la structure de données après correction

Après chaque changement du payload, cliquez sur « Re-determine data structure ». C’est le seul moyen de mettre à jour la structure côté Make. Vous pouvez aussi supprimer le webhook et le recréer. Dans la pratique, je préfère le bouton, car il conserve l’URL existante.

Comparer le payload Make avec le format attendu par votre API

Alignez le JSON : champs obligatoires, types de données, encodage. Si votre API attend une date au format ISO, Make doit l’envoyer dans ce format. Méfiez-vous des conversions automatiques. Make transforme parfois les nombres en chaînes. Ajoutez un module de transformation si nécessaire.

La checklist finale avant d’ouvrir un ticket support Make

Je ne contacte le support Make qu’après avoir vérifié cinq points : scénario actif, URL correcte, payload valide, structure re-déterminée, endpoint testé avec webhook.site. Dans 95 % des cas, le problème vient de ma configuration, pas de Make. Et si vous voulez ma vérité de terrain : la plupart des erreurs 400 sur Make.com sont dues à un JSON malformé ou à un scénario inactif. La 500, elle, cache un bug dans votre code. Vous savez maintenant comment débugger un statut 400 ou 500 sur un webhook Make.com, sans perdre votre après-midi. Si vous êtes confronté à une autre erreur récurrente, découvrez comment résoudre l’erreur quota exceeded Make.com.