Le nœud HTTP Request de n8n sert à envoyer des requêtes HTTP depuis un workflow, notamment vers une API REST. Pour éviter les exemples artificiels, voici un GET public réellement vérifié en lecture : https://www.gridpak.com/wp-json/wp/v2/posts?per_page=1. Il répond en JSON public sans authentification pour lire un article WordPress exposé par l’API REST.
Repère documentaire : documentation officielle du fonctionnement présenté.
Ce guide documentaire décrit une procédure à vérifier sur votre installation ; nous ne présentons pas ces manipulations comme un test exécuté.
Configurer le GET
- Méthode :
GET. - URL :
https://www.gridpak.com/wp-json/wp/v2/posts. - Query parameter :
per_page=1. - Response : activez l’option qui inclut le status code et les headers si vous devez distinguer body, code HTTP et pagination.
La structure attendue est un tableau JSON. Le premier élément contient notamment id et title.rendered. Dans n8n, vous devez donc traiter une liste d’items, pas un objet unique. Si votre étape suivante attend un seul article, prenez le premier item ou ajoutez une boucle explicite.
curl --max-time 20 'https://www.gridpak.com/wp-json/wp/v2/posts?per_page=1'Lecture publique ne veut pas dire écriture autorisée
Ce GET lit des données publiques. Il ne permet pas de créer ou modifier un article. Pour un POST WordPress, il faut une authentification valide et des droits. La logique n8n doit donc séparer : lecture sans credentials quand l’API l’autorise ; écriture seulement avec credentials, permissions et garde-fous.
Status code et erreurs
Ne parsez pas seulement le body. Activez le retour du status quand le workflow doit réagir différemment à 200, 401, 404 ou 429. Un body JSON d’erreur peut ressembler à un objet valide mais signaler un refus. Stockez aussi l’URL appelée, la méthode, le status et un extrait court de l’erreur, pas forcément tout le payload si des données personnelles circulent.
Pagination
La pagination dépend du service appelé. WordPress expose par exemple per_page et page, avec des limites côté API. D’autres services utilisent limit/offset, un curseur ou un lien next. Dans n8n, configurez la pagination seulement après avoir observé la forme réelle de la réponse et des headers. N’inventez pas un maximum universel.
POST, retries et doublons
Un retry automatique sur GET est généralement peu risqué. Sur POST, il peut créer deux commandes, deux tickets ou deux paiements si l’API n’est pas idempotente. Quand vous envoyez une création, utilisez si possible une clé d’idempotence ou un ID métier côté payload. Exemple : external_id: CMD-2026-004218. Si le premier appel timeout mais réussit côté serveur, le retry doit pouvoir retrouver ou mettre à jour la même ressource, pas en créer une deuxième.
Checklist
- Tester l’URL avec curl et timeout.
- Vérifier status code, headers utiles et type JSON.
- Documenter si la racine est tableau ou objet.
- Limiter les logs de payloads sensibles.
- Définir la stratégie retry selon GET ou POST.
Un bon nœud HTTP Request est ennuyeux : URL claire, paramètres visibles, réponse attendue documentée, erreur exploitable et aucun effet de bord caché.
Mapper la réponse dans n8n
Après le GET Gridpak, un champ de titre peut se lire comme {{$json.title.rendered}} si n8n a déjà éclaté le tableau en items. Si le tableau reste dans un seul item selon votre configuration, il faut d’abord sélectionner l’index zéro. Avec Include Response Headers and Status, le corps est sous body : inspectez la sortie, puis adaptez le chemin, par exemple {{$json.body[0].title.rendered}} si body contient le tableau. La différence explique beaucoup de workflows qui marchent dans curl mais pas dans n8n.
Headers utiles
Sur certaines APIs, les headers donnent le nombre total, la page suivante ou la limite restante. Ne les ignorez pas si vous paginez. À l’inverse, ne stockez pas tous les headers si l’un d’eux peut contenir un token ou un cookie. Gardez seulement ce qui sert au diagnostic ou au contrôle de flux.
Écriture WordPress
Pour créer un post, préparez un brouillon et vérifiez la réponse. WordPress REST ne transforme pas un champ arbitraire external_id en clé d’idempotence : votre intégration doit stocker et contrôler l’association entre identifiant source et ID WordPress. Si le POST timeout, faites un GET de contrôle avant retry. Sinon, vous pouvez créer deux brouillons presque identiques. C’est la différence entre automatisation fiable et générateur de déchets.
Séparer configuration et secrets
Dans n8n, gardez l’URL de base, les paramètres et les credentials lisibles séparément. Un nœud HTTP rempli avec une URL géante et un token collé dans le query string devient difficile à auditer. Préférez credentials n8n pour les secrets, query parameters pour les filtres, headers pour les formats acceptés, et variables d’environnement quand plusieurs environnements existent.
Pour les APIs tierces, documentez aussi les limites : nombre d’appels par minute, pagination maximale, politique retry, erreurs connues. Le nœud HTTP Request est simple à poser, mais c’est cette fiche d’exploitation qui évite les pannes silencieuses.
Dry-run métier
Pour une API d’écriture, commencez avec un endpoint de test ou un statut brouillon. Vérifiez la ressource créée par un GET de contrôle. Ce double contrôle évite de confondre “requête acceptée par n8n” et “objet correct côté service”.
Timeouts
Ajoutez un timeout cohérent avec le service appelé. Un workflow bloqué sur une API lente peut occuper des exécutions, retarder les étapes suivantes et masquer la vraie cause de panne.
Rejeu contrôlé
Conservez un exemple de réponse anonymisé pour tester le workflow sans appeler l’API à chaque modification. Cela accélère les corrections de mapping et évite de consommer inutilement le quota du service réel.
Pour les bases : définition d’une API REST.
