En el tutorial anterior tu workflow escuchaba peticiones con un Webhook. Ahora toca la dirección contraria: que el workflow salga a pedir datos. Con el nodo HTTP Request consultas una API externa desde n8n, revisas la respuesta y usas parte de sus datos en el resto del flujo. Lo haremos con una API pública que no pide claves ni registro.
Qué hace HTTP Request
El nodo HTTP Request envía una petición HTTP a un servicio externo y trae la respuesta de vuelta al workflow. En esquema:
n8n → HTTP Request → API externa → respuesta JSONMientras que el nodo Webhook espera a que alguien llame a tu workflow, HTTP Request es el que sale a llamar. La respuesta queda disponible en el nodo y los siguientes pueden leer sus campos con expresiones.
Requisitos previos
- Una instancia de n8n funcionando. Si no la tienes, sigue primero cómo instalar n8n con Docker.
- Conocimientos básicos de workflows: nodos, conexiones y ejecución manual en cómo crear tu primer workflow en n8n.
- Saber ejecutar manualmente un flujo. Es lo que usarás para lanzar la petición durante las pruebas.
En el tutorial de webhooks viste cómo recibir peticiones; aquí verás cómo emitirlas.
Crear el workflow
Abre n8n y crea un workflow nuevo con este flujo mínimo:
Manual Trigger → HTTP Request → Edit FieldsTres nodos, sin añadidos. El Manual Trigger permite probar a mano, HTTP Request hace la consulta y Edit Fields recoge un dato de la respuesta.
Añadir HTTP Request
Añade el nodo HTTP Request en el lienzo y conéctalo al Manual Trigger. Es el nodo actual de n8n para peticiones HTTP; lo encuentras buscando HTTP Request en el panel de nodos.
Elegir método HTTP
En el nodo, deja el campo Method en GET.
GET se usa normalmente para consultar datos: pedir algo a una API sin modificarlo. Es el método correcto para este ejemplo. Los métodos POST, PUT, PATCH y DELETE sirven para enviar o modificar información, y los verás más adelante en este artículo.
Configurar la URL
Abre el nodo HTTP Request y pega la URL de la API en el campo URL:
https://catfact.ninja/factEs una API pública y estable que devuelve un dato curioso sobre gatos en JSON, sin claves, cuentas ni autenticación. El campo URL es donde va el endpoint: la dirección exacta de la API a la que quieres llamar.
Con esto, el nodo queda configurado: Method GET, URL la de arriba y autenticación en None.
Ejecutar la petición
Para probar solo este nodo, ábrelo y pulsa el botón Test step del panel: ejecuta únicamente el HTTP Request y muestra su resultado, sin tocar el resto del workflow.
Para probar el flujo completo, utiliza Execute Workflow: n8n ejecuta en cadena desde el Manual Trigger. El HTTP Request tarda un instante en responder; si todo va bien, el nodo queda marcado como correcto.
Revisar la respuesta
Abre el output del nodo HTTP Request. La API de catfact devuelve un objeto JSON con dos campos. Una llamada real produce algo como:
{
"fact": "Approximately 24 cat skins can make a coat.",
"length": 43
}Los campos son siempre los mismos, aunque el texto de fact cambie en cada llamada:
fact: una frase sobre gatos (string).length: el número de caracteres de esa frase (número).
Además del JSON, n8n adjunta al item los headers y el statusCode de la respuesta. No hay campos anidados: el JSON llega en la raíz.
Usar un valor de la respuesta
Añade un nodo Edit Fields después del HTTP Request y extrae los dos campos de la respuesta. Como el JSON está en la raíz, las expresiones actuales de n8n son:
| Name Value | |
|---|---|
hecho |
{{ $json.fact }} |
longitud |
{{ $json.length }} |
Ejecuta de nuevo. La salida del Edit Fields es un objeto con hecho y longitud conteniendo los datos reales de la API. Si el dato estuviera anidado, la ruta cambiaría (p. ej. {{ $json.data.fact }}), pero en este endpoint no hace falta.
Query Parameters
Los query parameters son pares campo=valor que se añaden a la URL tras un ? para ajustar la petición: filtros, límites u opciones que la API entienda:
https://catfact.ninja/fact?max_length=50La API de catfact soporta max_length para acotar la longitud del texto, y está documentado. En el nodo, activa Send Query Parameters y añade el par:
| Name Value | |
|---|---|
max_length |
50 |
La llamada devuelve entonces un fact más corto y un length coherente con esa longitud. Es solo un ejemplo real de cómo pedir a la API un resultado ajustado; cada API define los query parameters que entiende.
Headers
Los headers transportan metadatos sobre la petición: qué formato envías, qué esperas recibir o quién te identifica. En el nodo se configuran con Send Headers.
Los tres habituales:
- Accept: el formato de la respuesta que quieres recibir.
- Content-Type: el formato del body cuando envías datos, por ejemplo
application/json. - Authorization: dónde suele viajar la credencial si la API lo exige.
Muchas APIs exigen headers concretos para funcionar; the catfact no necesita ninguno. Aquí no añades autenticación todavía, solo tienes en cuenta que esta opción existe.
Enviar JSON con POST
HTTP Request no solo consulta: también envía datos. Para demostrarlo sin inventar un endpoint, usamos https://httpbin.org/post, un servicio de prueba estable que responde devolviendo la petición que le envías, lo que permite comprobar el resultado.
Configura el nodo así:
- Method:
POST. - URL:
https://httpbin.org/post. - Send Body activado y Body Content Type:
JSON. - En el body, este JSON:
{
"nombre": "Mateo",
"servicio": "Automatización"
}httpbin hace eco de lo recibido en su respuesta. Los datos que enviaste aparecen en el campo json de la salida (la respuesta tiene más campos, como args, data o headers, pero lo relevante está en json). Este es el patrón de un POST: el servicio interpreta el body y responde en consecuencia.
Respuesta y status code
Toda respuesta HTTP incluye un código de estado. Los que verás con más frecuencia:
| Código | Significado |
|---|---|
| 200 | Correcto. La petición funcionó. |
| 201 | Correcto y algo se ha creado. |
| 400 | Petición mal formada. |
| 401 | Falta autenticación o es inválida. |
| 403 | Sin permiso para acceder, aunque estés autenticado. |
| 404 | No existe el recurso o el endpoint. |
| 429 | Demasiadas peticiones (rate limit). |
| 500 | Error interno del servidor remoto. |
En n8n, una respuesta con código de error (4xx o 5xx) suele marcar el nodo como fallido. Si ves un número de estos en un log o en la respuesta, ya sabes a qué atenerse.
Errores frecuentes
- URL incorrecta: un typo en el endpoint provoca un error de DNS o un 404. Copia la URL exacta de la documentación de la API.
- Endpoint caído: la API no responde o da error de conexión. Por eso el ejemplo usa una API estable, verificada y sin claves.
- Método incorrecto: enviar un POST a un endpoint que solo acepta GET (o al revés) devuelve un error de método. Revisa qué pide la API.
- JSON inesperado: la estructura de la respuesta no coincide con la esperada. Mírala en el output antes de escribir expresiones.
- Expresión apuntando a un campo que no existe: si
{{ $json.fact }}no devuelve nada, comprueba el nombre exacto y la ruta del campo en la salida real del nodo. - Falta de autenticación: las APIs protegidas devuelven 401/403 si no envías la credencial.
- Rate limit: el 429 indica que superaste el límite de peticiones; espera o reduce la frecuencia.
- Certificado HTTPS inválido: un error SSL aparece si el certificado no es válido. Existe la opción Ignore SSL Issues en Options, pero úsala solo para probar en desarrollo, nunca como solución de producción.
- Si el problema es que la instancia misma no responde, revisa los logs del contenedor de n8n.
Timeout y respuestas lentas
Algunas APIs tardan en responder o fallan por mucho trabajo en el servidor remoto. El nodo HTTP Request tiene una opción Timeout en Options para controlarlo.
No la aumentes sin motivo: un timeout demasiado amplio enmascara un fallo real y deja el workflow esperando más de la cuenta. Mantén el valor por defecto salvo que la API concreta tenga respuestas normalmente lentas y lo exija.
APIs con autenticación
Muchas APIs requieren una credencial: API key, bearer token u OAuth2. En la práctica, la mayoría de servicios reales necesitarán una de ellas.
n8n separa las credenciales del workflow: se configuran en el campo Authentication del nodo y se guardan aparte del flujo. Puede usar una credencial predefinida cuando n8n soporta el servicio, o credenciales genéricas (header auth, basic auth, OAuth2, etc.) para APIs a medida. No vamos a configurar ninguna aquí; solo debes saber que el campo Authentication existe y que es ahí donde iría la credencial cuando la API lo pida.
Conectar HTTP Request con un Webhook
Combinando lo que ya sabes, este flujo conceptual permite recibir una petición, consultar una API y devolver el resultado:
Webhook → HTTP Request → Respond to WebhookQue un servicio externo llame a tu webhook, tu workflow consulte otra API, y el resultado viaje de vuelta al emisor. Es el patrón de una pasarela: n8n hace de intermediario entre dos sistemas. Recuerdas los detalles del mecanismo en cómo usar un Webhook en n8n.
Seguridad
- Si n8n ofrece un sistema de credenciales para el servicio, úsalo en lugar de pegar claves API en campos visibles del nodo.
- Usa siempre HTTPS en las URLs; evita llamar a endpoints http planos que envían datos sin cifrar.
- Valida los datos antes de enviarlos a servicios externos: no confíes ciegamente en lo que llega de otra aplicación.
- No registres tokens ni credenciales en logs innecesariamente; al depurar con errores, revisa que no vuelques una petición llena de secrets.
Qué aprender después
La consulta a APIs abre un mundo nuevo. Los siguientes pasos naturales son:
- APIs REST: para diseñar mejor rutas, métodos y recursos.
- Autenticación: API keys, bearer tokens y su configuración en n8n.
- OAuth2: el estándar de las APIs modernas.
- Manejo de errores: nodos como IF o Switch para reaccionar ante respuestas incorrectas.
- Paginación: APIs que devuelven resultados por páginas y cómo recorrerlas.
- Bases de datos: guardar en tu propio sistema lo que trae una API.
Conclusión
Ya haces peticiones HTTP desde n8n: consultaste una API real con GET, revisaste su JSON en el output, extrajiste campos con expresiones como {{ $json.fact }} y entendiste query parameters, headers, un POST con body y los códigos de error más comunes.
El siguiente tutorial natural es Cómo programar workflows en n8n: ahí automatizarás la ejecución para que tus flujos corran por sí solos en lugar de esperar a que los dispares manualmente.