Introducción

La mayoría de las APIs del mundo real rechazan las solicitudes sin autenticar. Antes de poder obtener datos de Stripe, publicar en Slack o consultar un CRM, necesitas demostrar quién eres. n8n lo gestiona mediante su sistema de Credentials: un almacén cifrado que mantiene los secretos fuera del JSON del workflow y permite reutilizar la misma configuración de autenticación en múltiples nodos.

Esta lección cubre los tres patrones que encontrarás en al menos el 80% de las integraciones: API keys enviadas como header, Bearer tokens y el flujo de authorization code de OAuth2. Al final sabrás cómo configurar cada uno en n8n y cómo conectarlos a un nodo HTTP Request cuando no exista un nodo nativo para el servicio destino.

API Keys y Headers personalizados

El patrón de autenticación más simple: el servicio te emite una clave estática y tú la envías en cada solicitud, generalmente como un header personalizado como X-API-Key o como parámetro de query.

En n8n, ve a Credentials > Add Credential > Header Auth. Indicas el nombre y el valor del header una sola vez, y n8n lo inyecta automáticamente en cada solicitud que use esa credencial.

Ejemplo: conectarse a una API del tiempo que requiere una clave en el header.

En el nodo HTTP Request, establece Authentication en Header Auth, selecciona tu credencial guardada y luego configura la solicitud:

{
  "method": "GET",
  "url": "https://api.weatherapi.com/v1/current.json",
  "qs": {
    "q": "Hanoi"
  }
}

n8n adjuntará el header automáticamente — nunca codificas la clave directamente en el nodo. Si la API espera la clave como parámetro de query (p. ej. ?apikey=...), usa en su lugar el tipo de credencial Query Auth en lugar de Header Auth. Misma idea, ubicación distinta.

Un error común es pegar la clave directamente en un nodo Set o en un campo de URL. Eso incrusta el secreto en el JSON del workflow, que se exporta, se versiona y se comparte. Usa siempre Credentials.

Bearer Tokens

Muchas APIs — especialmente las que siguen client credentials de OAuth2 o emiten JWTs de corta duración — esperan un header Authorization con esta forma exacta:

Authorization: Bearer <token>

En n8n esto sigue siendo una credencial Header Auth. Establece el campo Name en Authorization y el campo Value en Bearer seguido de un espacio y tu token:

Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

Si tu token expira y necesita renovarse de forma programada, añade un nodo HTTP Request previo que llame al endpoint de tokens, extrae el access_token de la respuesta con una expresión como {{ $json.access_token }} y pásalo al header Authorization del siguiente nodo. Esto crea un sencillo patrón de renovación de token con dos nodos sin necesidad de código personalizado.

Flujo de Authorization Code de OAuth2

OAuth2 con el flujo de authorization code es más complejo porque requiere un redirect del navegador — el usuario debe visitar al proveedor, iniciar sesión y conceder permiso antes de que n8n reciba un access token. n8n automatiza la mayor parte de este proceso.

Paso 1: crea una credencial OAuth2 API. Ve a Credentials > Add Credential > OAuth2 API. Rellena los campos desde el registro de tu app en el proveedor:

{
  "Grant Type": "Authorization Code",
  "Authorization URL": "https://accounts.google.com/o/oauth2/auth",
  "Access Token URL": "https://oauth2.googleapis.com/token",
  "Client ID": "your-client-id",
  "Client Secret": "your-client-secret",
  "Scope": "https://www.googleapis.com/auth/spreadsheets"
}

Paso 2: configura el redirect URI. n8n te muestra su URL de callback (algo como https://your-n8n-instance.com/rest/oauth2-credential/callback). Cópiala en el campo Authorized Redirect URIs de tu app OAuth en el panel del proveedor.

Paso 3: haz clic en Connect my account en n8n. Se abre una ventana emergente del navegador, inicias sesión y apruebas, y n8n guarda automáticamente los tokens de acceso y de refresco resultantes. A partir de este momento, n8n también gestiona la renovación de tokens en silencio: cuando el access token expira, usa el refresh token para obtener uno nuevo sin ninguna acción por tu parte.

Para nodos integrados como Google Sheets, Slack o HubSpot, n8n rellena automáticamente la Authorization URL y la Access Token URL — solo necesitas el Client ID, el Client Secret y la lista de scopes de la documentación del proveedor.

Errores comunes y cómo solucionarlos

401 Unauthorized casi siempre significa que la credencial está mal configurada o que el token ha expirado. Comprueba que el nombre del header coincida exactamente con lo que indica la documentación de la API — algunas APIs usan X-Auth-Token, otras usan api-key (en minúsculas), y la discrepancia pasa desapercibida hasta el runtime.

403 Forbidden significa que el token es válido pero carece del scope necesario. Vuelve a tu app OAuth, añade el scope faltante y vuelve a autorizar. n8n no vuelve a solicitar automáticamente nuevos scopes.

Si OAuth2 Connect falla con un error redirect_uri_mismatch, la URL de callback en n8n y la registrada en el proveedor no coinciden exactamente — revisa si hay barras diagonales finales o diferencias entre http y https.

Nunca almacenes secretos en expresiones del workflow ni en parámetros de nodos. n8n cifra todo en el almacén de Credentials usando la clave de cifrado de tu instancia. Si necesitas rotar una clave, actualízala una sola vez en la Credential y todos los workflows que la usen recibirán el cambio de inmediato.

Resumen

Usa Header Auth para API keys estáticas, usa headers de Bearer token para tokens de corta duración con un paso de renovación si es necesario, y usa el tipo de credencial OAuth2 Authorization Code para la autorización delegada de usuarios. En todos los casos, almacena los secretos en las Credentials de n8n — nunca en línea dentro de los workflows. El nodo HTTP Request funciona con los tres patrones mediante su desplegable Authentication, lo que lo convierte en tu recurso de fallback para cualquier servicio que no tenga un nodo específico de n8n.