Cómo conectar una API REST con n8n
El nodo HTTP Request permite conectar n8n con prácticamente cualquier servicio que disponga de una API REST. Con él puedes consultar información, enviar formularios, crear registros y trasladar datos entre aplicaciones aunque n8n no tenga un nodo específico para ellas.
En esta guía aprenderás a configurar una petición desde cero, utilizar parámetros y cuerpos JSON, proteger las credenciales, procesar la respuesta y gestionar errores, paginación y límites de uso.
Qué necesitas antes de empezar
Antes de construir el workflow, consulta la documentación oficial de la API que quieres utilizar. Debes localizar al menos los siguientes datos:
- La URL base y el endpoint concreto.
- El método HTTP requerido: GET, POST, PUT, PATCH o DELETE.
- El sistema de autenticación: API key, Basic Auth, Bearer token u OAuth2.
- Los parámetros obligatorios y el formato del cuerpo.
- La estructura de la respuesta.
- Los límites de peticiones y códigos de error posibles.
No pruebes inicialmente con datos importantes. Utiliza una cuenta de desarrollo, un entorno de pruebas o registros que puedas eliminar después.
Métodos HTTP principales
| Método | Uso habitual |
|---|---|
| GET | Consultar uno o varios recursos |
| POST | Crear un recurso o ejecutar una acción |
| PUT | Reemplazar completamente un recurso |
| PATCH | Modificar parcialmente un recurso |
| DELETE | Eliminar un recurso |
Una petición de lectura con GET es un buen punto de partida porque normalmente no modifica datos. Una vez confirmada la conexión, puedes avanzar hacia operaciones de escritura.
Ejemplo práctico con el nodo HTTP Request
Vamos a realizar una prueba con JSONPlaceholder, una API pública diseñada para ejemplos. No necesita credenciales y evita utilizar información real.
1. Crear el workflow
- Entra en n8n y crea un workflow nuevo.
- Añade el nodo Manual Trigger.
- Añade un nodo HTTP Request.
- Conecta Manual Trigger con HTTP Request.
2. Configurar la petición GET
Dentro de HTTP Request establece estos valores:
- Method: GET
- URL: https://jsonplaceholder.typicode.com/posts/1
- Authentication: None
Pulsa Execute step. Si la solicitud funciona, n8n mostrará una respuesta JSON parecida a esta:
{
"userId": 1,
"id": 1,
"title": "Título del artículo",
"body": "Contenido del artículo"
}Los campos de esa respuesta estarán disponibles para los nodos posteriores. Por ejemplo, una expresión puede recuperar el título mediante:
{{ $json.title }}Añadir parámetros de consulta
Muchas API permiten filtrar resultados mediante parámetros de consulta. En lugar de construir la URL manualmente, activa Send Query Parameters y añade cada parámetro con su nombre y valor.
Por ejemplo, para consultar los artículos del usuario 1 puedes utilizar:
- URL: https://jsonplaceholder.typicode.com/posts
- Query parameter: userId
- Value: 1
n8n generará una petición equivalente a https://jsonplaceholder.typicode.com/posts?userId=1.
Enviar un cuerpo JSON con POST
Para crear un recurso cambia el método a POST, activa Send Body y selecciona JSON como tipo de contenido. Un cuerpo de ejemplo sería:
{
"title": "Workflow creado con n8n",
"body": "Contenido enviado mediante una API REST",
"userId": 1
}En un workflow real puedes sustituir los valores fijos por expresiones procedentes de nodos anteriores:
{
"title": "{{ $json.title }}",
"body": "{{ $json.content }}",
"userId": "{{ $json.userId }}"
}Comprueba siempre qué campos exige la API. Algunas reciben JSON, mientras que otras esperan datos de formulario, archivos binarios o parámetros incluidos en la URL.
Cómo configurar la autenticación
Las API privadas necesitan alguna forma de autenticación. El nodo HTTP Request permite utilizar tipos de credenciales predefinidos y métodos genéricos.
- Predefined Credential Type: reutiliza las credenciales de un servicio compatible con n8n.
- Header Auth: envía una clave mediante una cabecera personalizada.
- Bearer Auth: utiliza un token en la cabecera Authorization.
- Basic Auth: autentica mediante usuario y contraseña.
- OAuth2: autoriza el acceso sin guardar directamente la contraseña del usuario.
Guarda las claves en el gestor de credenciales de n8n. No escribas tokens directamente en un nodo, en una expresión, en una captura de pantalla ni en el nombre del workflow. Esto reduce el riesgo de exponerlos al exportar o compartir la automatización.
Procesar la respuesta de la API
Una respuesta puede contener un único objeto, una lista de elementos o una estructura anidada. Ejecuta primero el nodo y examina la pestaña de salida antes de escribir expresiones.
Después puedes conectar nodos como Edit Fields, If, Filter o Code para seleccionar campos, comprobar condiciones y adaptar los datos. Evita depender de una propiedad sin comprobar que existe, especialmente cuando la API puede devolver respuestas diferentes ante un error.
Gestionar la paginación
Muchas API limitan la cantidad de resultados por respuesta. Si ignoras la paginación, el workflow puede procesar solamente la primera página y dejar datos sin recuperar.
En las opciones de paginación del nodo HTTP Request puedes configurar que n8n actualice un parámetro como page u offset, o que utilice la URL de la página siguiente devuelta por la API. El método exacto depende de la documentación del servicio.
- Por número de página: page=1, page=2, page=3.
- Por desplazamiento: offset=0, offset=100, offset=200.
- Por cursor: la respuesta entrega un identificador para solicitar el siguiente bloque.
- Por enlace: la respuesta incluye directamente la siguiente URL.
Límites de peticiones y reintentos
Cuando una API recibe demasiadas solicitudes puede responder con el código 429. Para reducir este problema, procesa los elementos por lotes, introduce pausas con el nodo Wait y respeta las cabeceras o límites indicados por el proveedor.
En la pestaña Settings del nodo puedes activar Retry On Fail y definir el número de intentos y el intervalo entre ellos. Utiliza esperas progresivas y limita los reintentos: insistir inmediatamente puede prolongar el bloqueo o duplicar una operación.
Códigos de estado que debes reconocer
| Código | Significado habitual |
|---|---|
| 200 | Petición completada correctamente |
| 201 | Recurso creado correctamente |
| 400 | Parámetros o cuerpo incorrectos |
| 401 | Credenciales ausentes o inválidas |
| 403 | La cuenta no tiene permiso |
| 404 | Endpoint o recurso inexistente |
| 429 | Límite de peticiones superado |
| 500–599 | Error temporal o interno del servidor |
No trates todos los fallos de la misma forma. Un 401 suele requerir revisar las credenciales, mientras que un 429 o un error 5xx puede admitir un nuevo intento después de esperar.
Buenas prácticas de seguridad
- Concede a cada clave únicamente los permisos necesarios.
- Utiliza HTTPS y evita servicios que transmitan credenciales sin cifrar.
- No registres respuestas completas si contienen datos personales o secretos.
- Valida los datos antes de enviarlos a otra aplicación.
- No permitas que una entrada pública controle libremente la URL solicitada.
- Rota las claves expuestas y elimina las que ya no se utilizan.
- Prueba primero con una cantidad pequeña de elementos.
Una URL controlada por un usuario podría hacer que el servidor solicite recursos internos. Si el endpoint se construye con datos externos, limita los dominios permitidos y valida el protocolo, el host y la ruta.
Errores frecuentes
- Confundir parámetros de consulta con campos del cuerpo.
- Enviar texto o formulario cuando la API espera JSON.
- Olvidar el prefijo Bearer en la cabecera Authorization.
- Procesar solamente la primera página de resultados.
- Reintentar operaciones POST sin comprobar si el recurso ya fue creado.
- Activar el workflow antes de probar sus rutas de error.
Preguntas frecuentes
¿Puedo conectar una API que no tenga nodo propio?
Sí. Si el servicio ofrece una API accesible por HTTP y tienes autorización para utilizarla, normalmente puedes conectarlo mediante HTTP Request.
¿Debo usar HTTP Request si existe un nodo oficial?
El nodo oficial suele ser más sencillo. HTTP Request resulta útil cuando necesitas un endpoint o una opción que el nodo específico todavía no incluye.
¿Cómo evito crear registros duplicados?
Busca primero el recurso mediante un identificador estable, utiliza funciones de idempotencia si la API las ofrece y guarda el identificador devuelto después de crear cada registro.
¿Qué información debo guardar en los registros?
Guarda el código de estado, el momento de ejecución y un identificador útil para investigar el fallo. Evita almacenar tokens, contraseñas o respuestas con información sensible.
Conclusión
La mejor forma de conectar una API REST con n8n es comenzar con una petición GET pequeña, confirmar la respuesta y añadir después autenticación, transformación de datos, paginación y control de errores. Antes de activar el workflow, comprueba qué ocurrirá si la API tarda, rechaza la petición o devuelve datos incompletos.
Cuando esa base funciona, el mismo patrón permite integrar herramientas de marketing, bases de datos, plataformas de contenido y servicios internos sin exponer las credenciales ni depender de procesos manuales.