Nodo HTTP Request n8n: guía completa 2026
El nodo HTTP Request de n8n es la navaja suiza que usás cuando la API que necesitás conectar no tiene un nodo nativo en la plataforma — y créeme, pasa más seguido de lo que parece. Con este nodo podés hacer llamadas GET, POST, PUT, PATCH y DELETE a cualquier endpoint, manejar autenticación, headers custom, body en JSON y hasta paginación, todo sin escribir una sola línea de código externo.
El nodo HTTP Request en n8n es un conector universal que envía peticiones HTTP a cualquier URL y devuelve la respuesta estructurada para que el resto de tu workflow la procese. Lo desarrolló el equipo de n8n como parte del core de la herramienta, y funciona con cualquier API REST documentada — internas, gubernamentales, SaaS niche, lo que sea — en menos de 10 minutos de configuración.
En 30 segundos
- Soporta GET, POST, PUT, PATCH y DELETE — elegís el método según lo que espera la API de destino, y n8n se encarga del resto.
- Cinco tipos de autenticación disponibles — desde API Key en header o query param, Bearer Token, Basic Auth, hasta OAuth2 completo.
- Body en JSON, Form Data o binarios — mandás datos estructurados, archivos multipart o formularios URL-encoded con expresiones n8n.
- Paginación automática en tres modos — offset/limit, cursor y Link Header, configurables desde las opciones del nodo sin código extra.
- Reintentos y manejo de errores integrados — activás “Continue on Fail”, configurás reintentos con espera, y combinás con nodos IF para rate limits 429 y errores 500.
¿Qué hace el nodo HTTP Request en n8n?
Ponele que estás automatizando un proceso y necesitás pegarle a la API de una herramienta que no aparece en el catálogo de n8n — un sistema de facturación interna, un endpoint de datos del gobierno, la API de tu CRM local. El nodo HTTP Request es lo que usás en ese momento.
Envía una petición HTTP a la URL que le indiques y te devuelve la respuesta parseada en JSON para que los nodos siguientes del workflow la procesen. Nada más, pero también nada menos. Según la guía publicada por PiratePrentice en dev.to, este nodo es “uno de los más poderosos de n8n” y la mayoría de los usuarios nunca lo explota a fondo.
Los campos clave que vas a configurar son: Method —GET, POST, PUT, PATCH o DELETE—, URL —donde podés usar expresiones de n8n como { $json.apiEndpoint }—, y Authentication, que es donde la mayoría se traba la primera vez. También tenés Headers para enviar tokens o definir el Content-Type, Query Parameters para filtrar resultados, y el Body cuando el método es POST o PUT.
¿La gran ventaja? Si la API tiene documentación pública, la conectás en menos de 10 minutos. Sin nodo nativo, sin esperar a que n8n lo agregue, sin código externo.
¿Cómo configurar la autenticación en el nodo HTTP Request?
Acá es donde el nodo HTTP Request muestra los dientes. n8n te da cinco opciones de autenticación, y la que elijas depende enteramente de lo que pida la API a la que le estás pegando. La configuración se hace desde la pestaña Authentication del nodo, y lo ideal es usar el sistema de credenciales de n8n en vez de hardcodear tokens — así no dejás claves sueltas en el workflow.
Para APIs públicas sin seguridad, elegís None. Pero eso es raro. Lo más común hoy es API Key, que podés mandar como header (tipo X-API-Key: tu-clave) o como query parameter. La opción Bearer Token agrega automáticamente el header Authorization: Bearer tu-token. Para APIs más viejas está Basic Auth con usuario y contraseña. Y para servicios como Google o Slack, tenés OAuth2 completo con redirect URI y refresh tokens. Complementá con enviar notificaciones a Slack con n8n.
Un tip importante: usá siempre el tipo de credencial genérico que corresponda desde el menú de n8n, no escribas los tokens a mano en los headers. Si rotás la API key en el futuro, la cambiás en un solo lugar y todos los workflows que la usan se actualizan.
Tabla comparativa de métodos de autenticación
| Método | Cuándo usarlo | Configuración en n8n |
|---|---|---|
| None | APIs públicas sin seguridad | Sin credenciales |
| API Key (Header) | APIs modernas con clave en header | Generic Credential → API Key |
| API Key (Query) | APIs que piden clave en URL | Generic Credential → API Key (query) |
| Bearer Token | OAuth simplificado o JWT | Generic Credential → Bearer Token |
| Basic Auth | APIs legacy con user/pass | Username y Password en credenciales |
| OAuth2 | Google, Slack, Microsoft, etc. | OAuth2 con redirect URI y scopes |
¿Cómo enviar datos en el body (JSON, Form Data, Binarios)?
Cuando el método es POST, PUT o PATCH, necesitás mandar datos en el cuerpo de la petición. El nodo HTTP Request te da tres formatos, y elegir el equivocado es el error más común que veo en workflows de producción.
JSON es el estándar para APIs REST modernas. Tenés dos formas de configurarlo: usando el modo JSON Input donde pegás el JSON directamente (útil cuando el payload ya viene armado de un nodo anterior), o con campos individuales donde n8n te deja construir el objeto campo por campo usando expresiones como { $json.nombre }. El segundo modo es más mantenible cuando el workflow crece.
Multipart Form Data es para cuando necesitás subir archivos — imágenes a una CDN, documentos a un sistema de gestión, PDFs generados en el workflow. Configurás cada parte con su nombre, tipo y contenido. Y Form URL-Encoded es el formato viejo de formularios HTML, que todavía usan algunas APIs de autenticación para intercambiar códigos de autorización por tokens.
Ojo con el Content-Type: si mandás JSON, asegurate de que el header Content-Type: application/json esté presente. Lo mismo para Form Data (multipart/form-data) y URL-Encoded (application/x-www-form-urlencoded). n8n suele setearlo automáticamente según el modo que elegiste, pero revisalo la primera vez.
¿Cómo manejar la paginación en llamadas API?
Ponele que le pegás a una API que devuelve 10.000 registros pero de a 100 por página. Si no configurás la paginación, tu workflow procesa solo los primeros 100 y el resto queda en el limbo, mientras vos te preguntás por qué faltan datos en el reporte final.
n8n soporta tres tipos de paginación directo en las opciones del nodo. El primero es Offset/Limit, que usan APIs como las de Airtable o Notion: mandás parámetros como offset=0&limit=100, y en cada iteración el offset aumenta. El segundo es Cursor, típico de APIs modernas como Stripe o Slack, donde la respuesta incluye un next_cursor y vos se lo pasás a la siguiente petición. En la guía para instalar n8n con Docker profundizamos sobre esto.
El tercer tipo, Link Header, es el que usan APIs como la de GitHub: la respuesta incluye headers HTTP del estilo Link: <url>; rel="next", y n8n los lee para saber cuándo seguir o parar. En los tres casos configurás la condición de finalización en Options > Pagination, y podés usar la variable $pageCount para limitar cuántas páginas traés como máximo (por las dudas de que la API no tenga fin y el workflow se vaya de largo).
La magia acá es que no necesitás un nodo Code extra ni armar un loop manual — n8n maneja la iteración, acumula los resultados y te los entrega en un solo array al nodo siguiente, siempre que configures bien el parámetro de paginación y el campo de donde sale el próximo token u offset.
¿Cómo gestionar errores y reintentos automáticos?
Si alguna vez tuviste un workflow que funcionaba en testing y en producción se caía a las dos horas, probablemente fue por un error de API no manejado. El nodo HTTP Request tiene dos mecanismos que tenés que conocer: Continue on Fail y Retry on Fail.
Activás Continue on Fail en la pestaña Settings del nodo. Lo que hace es simple: si la petición falla, el workflow no se detiene — sigue con el output del error para que vos decidas qué hacer. Combinado con un nodo IF que evalúe { $json.statusCode }, podés ramificar: si es 429 (rate limit), esperás y reintentás; si es 500, mandás una alerta; si es 404, registrás el error y seguís de largo. Sin este flag, cualquier error tira abajo todo el workflow, y eso en producción te deja sin datos y sin saber qué pasó.
El Retry on Fail está en las mismas opciones y te permite configurar cuántos reintentos hacer (ponele 3) y cuánto esperar entre cada uno (ponele 5 segundos). Para APIs con rate limiting, también podés configurar un retry específico cuando recibís un 429, con una espera que respete el Retry-After que la API te devuelve en el header. Esto te salva de tener que programar lógica de backoff exponencial a mano — n8n lo maneja solo.
La combinación ganadora es activar ambas opciones: Continue on Fail para que el workflow no muera, y Retry on Fail para darle una segunda oportunidad antes de mandar la alerta. Con eso cubrís el 90% de los escenarios de error sin escribir una línea de código.
¿Cómo usar cabeceras dinámicas y firmas HMAC?
Algunas APIs no se conforman con un token fijo — piden que firmes cada petición con HMAC, incluyendo un timestamp y una firma generada a partir de la clave secreta y el cuerpo de la petición. APIs de exchanges de cripto, pasarelas de pago, y sistemas bancarios suelen ser así. Y acá el nodo HTTP Request solo no alcanza — necesitás un nodo Code justo antes. Esto se conecta con lo que analizamos en automatizar tus tareas diarias con n8n.
Lo que hacés es simple: en el nodo Code generás el timestamp actual, calculás la firma HMAC-SHA256 con la clave secreta que tenés guardada en una variable de entorno (no la hardcodeés, por favor), y seteás los headers dinámicos: X-Timestamp, X-Signature, y lo que haga falta. Después en el nodo HTTP Request referenciás esos valores con expresiones como { $json.timestamp } y { $json.signature } en la sección Headers.
El patrón es el mismo para cualquier header que necesite ser calculado en runtime: un token JWT que expira cada hora y hay que regenerar, una firma AWS Signature V4, o un hash de integridad del body. El nodo Code hace el cálculo, el nodo HTTP Request lo manda. Separados, testeables, mantenibles.
Errores comunes al usar el nodo HTTP Request
Después de ver cientos de workflows en consultoría, estos son los errores que aparecen una y otra vez, y cómo esquivarlos.
No configurar el Content-Type. Mandás un JSON en el body pero el header Content-Type sigue en blanco o dice text/plain, y la API te responde 415 Unsupported Media Type. n8n no siempre lo infiere — revisalo en la sección Headers antes de pegarle al endpoint real.
Hardcodear tokens en vez de usar credenciales de n8n. Ves el campo Header, ponés Authorization: Bearer xyz123 a mano, y seis meses después rotan la clave y tenés que editar 40 workflows. Usá el sistema de credenciales desde el día uno — te ahorra un dolor de cabeza garantizado.
Ignorar la paginación y quedarse con la primera página de resultados. El workflow funciona bárbaro en testing porque la API de prueba tiene 5 registros, pero en producción hay 8.000 y vos estás procesando solo los primeros 100. Siempre revisá si la API pagina, y configuralo antes de pasar a producción.
Olvidar el Continue on Fail y que un error 429 tire todo abajo. Un rate limit temporal de 30 segundos te frena un workflow que corre cada 5 minutos y perdés horas de procesamiento hasta que alguien se da cuenta. Activá Continue on Fail aunque sea para loguear el error y seguir. Tema relacionado: la comparativa entre n8n, Zapier y Make.
Preguntas Frecuentes
¿Cómo llamar a cualquier API con n8n?
Usás el nodo HTTP Request, configurás el método (GET, POST, etc.), la URL del endpoint, y la autenticación que pida la API. Si no tiene un nodo nativo en n8n, este nodo es la vía universal para conectarte en menos de 10 minutos. La respuesta vuelve parseada en JSON para que los nodos siguientes la procesen.
¿Qué métodos HTTP soporta el nodo HTTP Request de n8n?
Soporta GET, POST, PUT, PATCH y DELETE. Elegís el que corresponda según la operación que querés hacer en la API: GET para leer, POST para crear, PUT/PATCH para actualizar, DELETE para borrar. La configuración se hace desde el dropdown Method en las opciones del nodo.
¿Cómo autenticar en n8n HTTP Request?
Tenés cinco opciones: None (APIs públicas), API Key en header o query param, Bearer Token, Basic Auth con usuario y contraseña, y OAuth2 completo. Lo recomendado es usar el sistema de credenciales de n8n desde la pestaña Authentication, no hardcodear tokens en los headers a mano.
¿Cómo manejar la paginación en el nodo HTTP Request de n8n?
n8n soporta tres modos de paginación: Offset/Limit, Cursor y Link Header. Los configurás en Options > Pagination del nodo, definiendo el parámetro de paginación, el campo del próximo cursor, y una condición de finalización. El nodo itera automáticamente y acumula todos los resultados en un array.
¿Cómo evitar que un error de API detenga todo el workflow en n8n?
Activás Continue on Fail en la pestaña Settings del nodo HTTP Request y combinás con un nodo IF que evalúe el statusCode. Así, si la API responde con un error 429 o 500, el workflow sigue su curso y vos decidís si reintentar, loguear o alertar, en vez de que todo se detenga.
Conclusión
El nodo HTTP Request es probablemente la pieza más subestimada de n8n. La mayoría lo usa para dos o tres llamadas simples y nunca toca las opciones de paginación, reintentos o credenciales genéricas. Y está bien para empezar, pero cuando tu workflow crece y empieza a mover datos de verdad, esas opciones son la diferencia entre un proceso robusto y uno que se cae cada martes a las 3 de la mañana.
Si estás corriendo n8n en un VPS propio —cosa que te recomiendo para tener control total sobre los workflows—, asegurate de que el entorno tenga buena conectividad y latencia baja, sobre todo si pegás a APIs externas. Para instancias auto-hospedadas en Argentina, opciones como Donweb te dan VPS con IP local y buen ancho de banda sin los problemas de ruteo que a veces tienen los proveedores de afuera. Pero eso ya es otra charla, para otro café.
Configurá la autenticación con credenciales, activá la paginación desde el día uno, y prendé Continue on Fail con reintentos. Son cinco minutos de configuración que te ahorran horas de debugging después.
Fuentes
- n8n HTTP Request Node: How to Call Any API (Free Workflow JSON) – dev.to — guía completa de configuración del nodo con ejemplos de autenticación y métodos.
- Nodo HTTP Request en n8n: guía avanzada para conectar cualquier API – n8n Hispano — cubre paginación, headers dinámicos y firmas HMAC en profundidad.
- Maestría del nodo HTTP Request n8n – El Diario IA — análisis de errores comunes y configuración de reintentos automáticos.
- n8n HTTP Request Node Guide – Synta.io — tutorial paso a paso con enfoque en autenticación y credenciales genéricas.
