En résumé

  • Une erreur 400 vient d’une requête mal formée ; une 500 vient d’un serveur qui plante.
  • Les causes principales d’une 400 : scénario inactif, JSON invalide, Content-Type incohérent, port non autorisé.
  • Capturez le payload avec webhook.site ou ngrok pour déboguer en conditions réelles.
  • Make relance automatiquement les requêtes qui échouent avec un 408, 429 ou 5xx, mais pas les autres 4xx.
  • Passez la checklist complète avant d’ouvrir un ticket support.

Comprendre l’erreur 400 et 500 : le réflexe à adopter en 30 secondes

Quand un webhook Make.com renvoie un statut 400 ou 500, la response HTTP du serveur vous indique où se situe le problème. Dans la plupart des cas, ces erreurs se corrigent en quelques minutes, à condition de savoir où regarder.

Le statut 400 Bad Request : une erreur côté client

Un code 400 Bad Request indique que le serveur destinataire a bien reçu votre requête, mais qu’il ne peut pas la traiter telle quelle. Autrement dit, Make a envoyé un payload invalide, un header Content-Type incohérent, ou une configuration de webhook incomplète. C’est une erreur côté client : c’est l’émetteur de la requête qui doit être corrigé.

Le statut 500 Internal Server Error : une erreur côté serveur

Un statut 500 signifie que la requête est arrivée correctement, mais que le serveur a planté pendant le traitement. Le problème ne se situe plus dans le format du message, mais dans l’exécution du code. Vous devez consulter les logs de votre serveur, pas le scénario Make.

Avant d’aller plus loin, vérifiez que votre scénario Make est actif et que le webhook est bien rattaché au bon module. C’est la cause n°1 d’une erreur 400 sur Make.com, devant les problèmes de JSON.

Pourquoi votre webhook Make renvoie une 400 ? Les 4 causes récurrentes

Quand le scénario est actif et que l’erreur persiste, examinez ces quatre points dans l’ordre.

JSON invalide : le piège des sauts de ligne non échappés

Un JSON mal formé provoque systématiquement une 400. Le piège classique est le saut de ligne non échappé dans une chaîne de caractères. Par exemple, un payload contenant « message » : « Ligne 1\nLigne 2 » doit avoir son retour à la ligne encodé en \n. Sans cet échappement, le serveur reçoit des données illisibles et renvoie une erreur.

Content-Type incohérent : application/json vs texte brut

Make envoie souvent un header Content-Type avec la valeur application/json. Si votre endpoint attend un autre type, comme text/plain ou application/x-www-form-urlencoded, la requête échoue. Vérifiez que le type de contenu annoncé par Make correspond à celui attendu par votre application.

Structure de données non re-déterminée après modification du body

Après une modification du body, Make peut continuer à utiliser l’ancienne structure de données. Résultat : une 400 inexpliquée. Cliquez sur le bouton « Re-determine data structure » pour forcer Make à recalculer le schéma attendu.

URL, ports et sécurité : Make n’envoie que vers les ports 80 et 443

Make ne peut pas envoyer de webhooks vers des ports autres que 80 et 443. Si vous testez en local sur un port custom, comme https://mon-api:8443/webhook, la requête échoue. Utilisez un reverse proxy ou un tunnel comme ngrok pour exposer votre service sur le bon port.

Comment voir ce que Make envoie réellement ? Capturez le payload brut

Pour debugger, il faut arrêter de supposer et observer la requête brute : headers, body, méthode HTTP. Voici les outils que j’utilise sur le terrain.

Utilisez un endpoint de capture temporaire (webhook.site, ngrok)

Le plus simple est de pointer votre webhook Make vers une URL de test comme webhook.site. Vous verrez immédiatement le message brut envoyé par Make. Si vous travaillez en local, ngrok expose votre serveur avec une URL publique et capture les requêtes entrantes. C’est l’outil idéal pour valider une configuration avant la mise en production.

Testez avec Postman : pourquoi ça passe chez vous mais pas en production

Un test Postman qui réussit ne garantit pas que Make fonctionnera. Postman envoie souvent des headers différents ou un format légèrement distinct. Si votre call passe mais que le webhook Make échoue, comparez les headers exacts et vérifiez l’environnement : firewall, SSL, reverse proxy.

Journalisez la requête entrante côté serveur

Pour voir exactement ce que reçoit votre endpoint, ajoutez un simple log. En Node.js avec Express, par exemple :

app.post(‘/webhook’, (req, res) => {

console.log(‘Request from Make:’, req.body);

res.status(200).send(‘OK’);

});

Ce log affiche le contenu du body et permet d’identifier immédiatement le champ problématique.

Codes HTTP et politique de retry de Make : échec permanent ou nouvelle tentative ?

Le statut retourné détermine si Make relancera automatiquement la requête. Cette distinction est essentielle pour choisir la bonne action.

Les codes 400-407 et 409-499 : échec permanent, pas de nouvelle tentative

Si votre endpoint répond avec un statut compris entre 400 et 407, ou entre 409 et 499, Make considère que la requête est définitivement incorrecte. Aucune nouvelle tentative n’est effectuée. C’est le cas typique d’un bad request causé par un payload mal formé. Vous devrez relancer le scénario manuellement après correction.

Les codes 408, 429 et 5xx : échec temporaire, relance automatique

Les statuts 408, 429 et tous les 5xx sont considérés comme temporaires. Make relance la requête avec un intervalle exponentiel. Une erreur 500 Internal Server Error est donc moins bloquante qu’une 400 : vous avez une fenêtre de correction avant la prochaine tentative.

Checklist finale avant d’ouvrir un ticket support

Prenez trente secondes pour passer cette liste en revue. Vous éviterez un aller-retour frustrant avec le support Make ou votre prestataire.

Vérifiez l’état du scénario, le webhook rattaché et la structure de données

  • Le scénario Make est-il actif ?
  • Le webhook est-il rattaché au bon module ?
  • La structure de données a-t-elle été re-déterminée après la dernière modification du body ?
  • L’URL utilise-t-elle HTTPS sur le port 80 ou 443 ?

Capturez le payload et inspectez les logs serveur

Redirigez le webhook vers webhook.site et comparez le JSON reçu avec le schéma attendu par votre endpoint. Vérifiez les noms de champs, les types et la casse. Si le statut est 500, consultez les logs de votre application et du serveur web : timeout, exception non capturée, WAF. Vous aurez ainsi les pièces à joindre au support : statut exact, payload capturé et logs.

Voici un tableau récapitulatif des statuts HTTP et des actions à mener :

Code HTTP Type d’erreur Action requise
400 – 407 Erreur client (payload, headers) Corriger la configuration Make, vérifier le JSON et le Content-Type
408 Timeout côté serveur Augmenter le timeout, optimiser le traitement
409 – 499 Erreur logique ou de ressource Corriger le payload ou l’état de l’application
429 Trop de requêtes Réduire la fréquence des appels, vérifier le rate limiting
5xx Erreur serveur interne Inspecter les logs serveur, corriger le plantage, vérifier le WAF

En suivant cette procédure, vous saurez rapidement si le problème vient de Make, du payload ou de votre serveur. Et vous aurez toutes les informations nécessaires pour résoudre l’erreur par vous-même ou pour ouvrir un ticket support efficace.