3. Conectar proveedores de IA: credenciales de Anthropic, OpenAI y Google

Descripción

En la lección anterior decidiste qué familia de modelo le conviene a tu agente — Claude, GPT o Gemini, según costo, latencia y calidad. Esa decisión, sola, no mueve ni un token: un nodo de modelo sin credencial es una puerta sin llave. Hoy vas a crear la credencial de cada proveedor, conectarla al nodo de modelo correcto dentro de tu agente, y — el punto que casi nadie te explica la primera vez — decidir cuándo te conviene reutilizar una credencial que ya existe y cuándo te conviene crear una nueva.

Esto importa apenas sales de un experimento personal. Si armas agentes para varios clientes — una agencia, un freelance, un equipo interno con distintos centros de costo — cada cliente suele traer su propia cuenta de OpenAI o Anthropic, y mezclar esas llaves en la credencial equivocada significa facturarle a un cliente el consumo de otro. Incluso solo, vas a querer una credencial separada para probar cosas en desarrollo y otra para lo que corre en producción, así una prueba mal escrita no te vacía la cuota del cliente real.

Conexión con el módulo: ya elegiste el modelo (lección 2); hoy conectas la llave que le da acceso real. La lección 5 asume que tu agente ya responde — así que sin esta lección resuelta, no hay prompt que probar.

Una credencial es una llave; cada proveedor es un edificio distinto

Piensa en Anthropic, OpenAI y Google como tres edificios de oficinas en la misma cuadra. Cada uno tiene su propia cerradura, y la llave de un edificio no gira ni un milímetro en la puerta del de al lado, por más que las tres parezcan del mismo metal. No importa cuánto insistas: una llave de OpenAI jamás va a abrir la puerta de Anthropic.

n8n no te obliga a cargar cada llave cada vez que la necesitas. Tiene algo parecido a un mostrador central de recepción con un llavero: guardas ahí la llave una sola vez, con un nombre que tú eliges, y desde cualquier workflow — hoy, el mes que viene, en un flujo completamente distinto — pides prestada esa misma llave sin volver a escribirla. Eso es, técnicamente, una credencial en n8n: un objeto cifrado, guardado aparte del workflow, identificado por un tipo (Anthropic API, OpenAI API, Google Gemini(PaLM) Api) que solo calza con los nodos que esperan justo ese tipo.

El nodo de modelo de chat — Anthropic Chat Model, OpenAI Chat Model o Google Gemini Chat Model, según el proveedor que elegiste — es la cerradura. Se conecta al puerto Chat Model de tu AI Agent, y en su panel tiene un campo "Credential to connect with" donde eliges qué llave del llavero usar. Un detalle que conviene tener claro desde ya: ese campo solo te ofrece credenciales de su mismo tipo. El nodo Anthropic Chat Model jamás te va a mostrar una credencial de OpenAI en su lista — el editor filtra por diseño, igual que la cerradura filtra por forma.

Ejemplo trabajado

Vamos a crear las tres credenciales, conectar una a un agente real, ejecutarlo, y después mirar qué queda guardado si exportas ese workflow.

Paso 1 — crea la credencial de Anthropic. En n8n, ve a Settings → Credentials → "Add credential" y busca "Anthropic API". El formulario pide:

Campo	Obligatorio	Qué poner
API Key	Sí	La key que generas en console.anthropic.com → Settings → API Keys → "Create Key"
Base URL	No	Déjalo vacío; por defecto usa https://api.anthropic.com
Add Custom Header	No	Actívalo solo si un proxy corporativo lo exige

Nombra la credencial de forma que dentro de seis meses sepas qué es sin abrirla — por ejemplo "Anthropic — Cliente Acme" en vez de "Anthropic API". Al guardar, n8n prueba la conexión sola (hace un GET /v1/models con tu key) y te avisa si el key es válido antes de que descubras el error a mitad de una ejecución.

Paso 2 — repite para OpenAI y Google. La mecánica es la misma; solo cambian los campos y de dónde sacas la key:

Proveedor	Tipo de credencial	Campo obligatorio	Campos opcionales	Dónde generar la key
OpenAI	OpenAI API	API Key	Organization ID, Base URL, header personalizado	platform.openai.com/api-keys
Google Gemini	Google Gemini(PaLM) Api	API Key	Host (déjalo en su valor por defecto)	aistudio.google.com/apikey

Para Google, el campo "Host" viene precargado con https://generativelanguage.googleapis.com y aparece editable, pero la documentación oficial es explícita: los nodos relacionados todavía no soportan un host o proxy distinto al de fábrica. Tocarlo no te da nada, solo riesgo de romperlo.

Paso 3 — conecta la credencial al nodo del agente. Abre tu workflow con el nodo AI Agent (el mismo que armaste en el módulo anterior) y en el puerto "Chat Model" agrega el sub-nodo que corresponda a tu proveedor — por ejemplo, "Anthropic Chat Model". En su panel, en "Credential to connect with", selecciona la credencial que acabas de crear. El campo "Model" se llena solo con un desplegable que consulta en vivo qué modelos puede usar esa cuenta específica — no una lista fija escrita en el nodo — así que si no ves ahí el modelo que decidiste en la lección anterior, el problema no es el nodo: es que esa cuenta todavía no tiene acceso a ese modelo.

Paso 4 — ejecuta y confirma. Con un mensaje de prueba como "¿Qué puedes hacer por mí?", ejecuta el nodo. Qué esperar: el panel de ejecución muestra una respuesta de texto en output, y si abres el detalle de la llamada, ves el nombre exacto del modelo que respondió — útil para confirmar que de verdad estás pegándole al modelo que crees, no a uno más viejo que quedó seleccionado por accidente.

Paso 5 — exporta el workflow y mira qué se guardó. Desde el menú de tres puntos, "Download". Busca el nodo del modelo dentro del JSON:

{
  "name": "Anthropic Chat Model",
  "type": "@n8n/n8n-nodes-langchain.lmChatAnthropic",
  "typeVersion": 1.3,
  "parameters": {
    "model": { "value": "claude-sonnet-4-5" }
  },
  "credentials": {
    "anthropicApi": {
      "id": "7",
      "name": "Anthropic — Cliente Acme"
    }
  }
}

Ahí está el detalle que importa: la clave credentials solo trae un id y un name. La API key real nunca sale de la base de datos de tu instancia de n8n — no viaja en el archivo exportado, no queda en un repositorio si subes el JSON, no aparece si un colega abre el archivo en un editor de texto. Si ese colega importa el workflow en su propia instancia, el id: "7" no existe ahí, así que n8n le va a pedir explícitamente que conecte su propia credencial antes de poder ejecutar el nodo.

Cuándo crear una credencial nueva y cuándo reutilizar la que ya tienes

La pregunta no es técnica, es organizativa. Algunos criterios que sí importan en la práctica:

• Por cliente o cuenta de facturación. Si armas agentes para distintos clientes y cada uno paga su propia cuenta de OpenAI o Anthropic, cada cliente necesita su propia credencial, nunca comparten una. Nómbralas sin ambigüedad ("OpenAI — Cliente Norte", "OpenAI — Cliente Sur") para que nadie conecte por error el workflow del cliente equivocado a la llave del otro.
• Por entorno. Una credencial para lo que pruebas en desarrollo y otra para lo que corre en producción, aunque las dos apunten a la misma cuenta real. Así un experimento que consume de más, o un prompt que quedó en un ciclo raro durante una prueba, no golpea el presupuesto que el cliente espera ver en producción.
• Rotación sin tocar cada nodo. Como los nodos referencian la credencial por id, no por el valor de la key, puedes rotar una API key vencida editando la credencial una sola vez — todos los workflows que la usan quedan actualizados sin que abras nodo por nodo.
• El campo Base URL / Host, para gateways reales. Algunos equipos ponen un proxy corporativo delante de la API del proveedor — para centralizar el gasto, aplicar un filtro de contenido, o loguear cada llamada — y ese proxy expone el mismo formato de API que el proveedor original. Ahí sí tiene sentido cambiar la Base URL de la credencial de Anthropic u OpenAI para que apunte al proxy en vez de a la API pública. Para Google esta puerta está cerrada por ahora: el Host queda fijo.
• Organization ID (solo OpenAI). Si tu cuenta pertenece a más de una organización de OpenAI, este campo asegura que el consumo se atribuya a la organización correcta en la facturación, en vez de a la que la cuenta usa por defecto.

Errores comunes

Pensar que cambiar de proveedor es solo cambiar la credencial en el mismo nodo. Es el error conceptual más común en quien recién llega de otras herramientas: asumir que un nodo genérico de "modelo de chat" acepta cualquier credencial y que basta con reemplazarla para saltar de Claude a GPT. En n8n no es así — Anthropic Chat Model, OpenAI Chat Model y Google Gemini Chat Model son tres tipos de nodo distintos, cada uno construido contra la API específica de su proveedor. Lo detectas porque el desplegable de credenciales de un nodo Anthropic Chat Model jamás va a listarte una credencial de OpenAI, sin importar cuántas tengas guardadas. La corrección es borrar el sub-nodo del proveedor viejo, agregar el del proveedor nuevo en el puerto Chat Model del agente, y recién ahí elegir o crear su credencial.

Pegar la API key en el campo del proveedor equivocado. Pasa más de lo que parece cuando tienes varias pestañas abiertas: copias la key de Anthropic y la pegas en el formulario de la credencial de OpenAI que quedó abierto de antes. El formulario la acepta sin quejarse — es un campo de texto, no valida formato al guardar — pero al ejecutar el nodo te encuentras con un error de autenticación (401, típicamente invalid_api_key o authentication_error según el proveedor). Lo detectas usando el botón "Test" del panel de credencial antes de darla por buena, no solo al guardar. Se corrige revisando de qué consola copiaste la key y regenerándola si hace falta.

Tocar el campo Base URL o Host sin necesidad real. Alguien copia la URL completa de un endpoint (por ejemplo, con /v1/messages al final) en vez del dominio raíz, o deja un espacio o una barra sobrante. La credencial se guarda sin error visible — el problema aparece recién al ejecutar, como un error de conexión o un 404, porque n8n arma la URL final concatenando el path del endpoint sobre lo que pusiste ahí. Lo detectas comparando tu valor contra el default documentado (https://api.anthropic.com, https://api.openai.com/v1, https://generativelanguage.googleapis.com). Se corrige dejando el campo en su valor por defecto salvo que de verdad estés apuntando a un proxy propio, y en ese caso, pegando solo el dominio raíz.

Ejercicios

Ejercicio 1. Creas una credencial de OpenAI, la conectas a un nodo "OpenAI Chat Model" en tu agente, y ejecutas. El nodo responde con un error de autenticación. Enumera, en orden, los tres primeros lugares donde revisarías antes de asumir que tu cuenta de OpenAI tiene un problema.

Ver solución

Primero, el botón "Test" de la credencial misma — si falla ahí, el problema es la key, no el nodo ni el workflow. Segundo, que la key efectivamente sea de OpenAI y no de otro proveedor pegada por error (revisar el prefijo: las keys de OpenAI empiezan con sk-, las de Anthropic con sk-ant-). Tercero, si el "Test" pasa pero la ejecución del nodo falla igual, revisar el campo Organization ID: una key válida pero asociada a la organización equivocada puede rechazar la llamada según cómo esté configurada la cuenta.

Por qué funciona: cada uno de estos tres puntos aísla una causa distinta del mismo síntoma (error de autenticación), y revisarlos en ese orden — credencial, key correcta, organización — descarta lo más simple antes de asumir un problema más raro de la cuenta.

Ejercicio 2. Tienes un solo nodo "Anthropic Chat Model" en un workflow, con una credencial llamada "Anthropic — Cliente Acme" conectada. Necesitas correr exactamente el mismo workflow para "Cliente Beta", que paga su propia cuenta de Anthropic. ¿Qué harías: editar la credencial existente, o crear una nueva? Justifica.

Ver solución

Crear una credencial nueva ("Anthropic — Cliente Beta"), nunca editar la existente. Si editas "Anthropic — Cliente Acme" para que apunte a la key de Beta, cualquier otro workflow que ya use esa credencial por su id — quizás uno que crees que era solo de Acme — empieza a facturarle a Beta sin que lo hayas decidido explícitamente ahí. Mantener una credencial por cliente hace que el consumo de cada uno quede aislado y sea auditable con solo mirar el nombre de la credencial que aparece en cada nodo.

Por qué funciona: como los nodos referencian la credencial por id, editar una credencial compartida propaga el cambio a todo lo que la use — un atajo cómodo para rotar una key propia, pero peligroso cuando lo que cambia es de quién es la cuenta.

Ejercicio 3. Exportas un workflow que usa una credencial de Google Gemini y se lo mandas a un colega para que lo revise en su propia instancia de n8n. Él lo importa e intenta ejecutarlo de inmediato. ¿Qué va a pasar, y qué le falta hacer antes de que funcione?

Ver solución

La ejecución va a fallar o el nodo va a pedir explícitamente una credencial, porque el archivo JSON exportado solo trae el id y el name de tu credencial de Google Gemini(PaLM) Api — nunca la API key en sí. Ese id no existe en la instancia de tu colega. Antes de ejecutar, él necesita crear su propia credencial de Google Gemini(PaLM) Api (con su propia key de Google AI Studio) y conectarla al nodo importado.

Por qué funciona: n8n cifra y guarda las credenciales por instancia, separadas del workflow; el export solo lleva una referencia, no el secreto. Es justo el mecanismo que te permite compartir o versionar workflows sin regalar tus llaves.

Ejercicio 4 (reto). Tu agente usa hoy un nodo "OpenAI Chat Model" con su credencial ya conectada y probada. Un cliente te pide cambiar a Gemini para esa misma tarea, sin cambiar nada más del comportamiento del agente. Describe los pasos concretos en el canvas — no solo "cambiar el modelo".

Ver solución

1. Agregar un nuevo sub-nodo "Google Gemini Chat Model" al canvas (no se puede reconvertir el nodo OpenAI existente, porque son tipos de nodo distintos).
2. Conectarlo al puerto "Chat Model" del AI Agent — esto reemplaza la conexión que tenía el nodo de OpenAI (el puerto acepta una sola conexión de tipo ai_languageModel).
3. En el panel del nuevo nodo, seleccionar o crear la credencial de Google Gemini(PaLM) Api, y elegir el modelo desde el desplegable que consulta la cuenta.
4. Eliminar el sub-nodo "OpenAI Chat Model" que quedó desconectado (opcional para que ejecute, pero recomendable para no dejar nodos huérfanos confundiendo a quien abra el workflow después).
5. Ejecutar de nuevo con el mismo prompt de prueba que usabas antes, para confirmar que el resto del agente — el system prompt, las tools, la memoria — sigue comportándose igual con el modelo nuevo.

Por qué funciona: el System Message, las tools y la memoria están conectados al nodo AI Agent, no al nodo de modelo — cambiar el "cerebro" no debería tocar esas piezas. Lo único que de verdad cambia es qué sub-nodo ocupa el puerto Chat Model y qué credencial trae.

Resumen y siguiente paso

Ya sabes crear una credencial para Anthropic, OpenAI y Google, conectarla al nodo de modelo correcto, y — más importante — decidir cuándo te conviene una credencial nueva en vez de reutilizar la que ya tienes: por cliente, por entorno, o para rotar una key sin tocar cada workflow que la usa. También viste que exportar un workflow nunca expone la key real, solo una referencia.

Lo que aprendiste hoy asume que hay una cuenta de nube detrás de cada credencial — y esas cuentas cuestan dinero por cada llamada. En la siguiente lección vas a ver la otra punta: correr el mismo agente contra un modelo que vive en tu propia máquina, sin credencial de nube ni costo por token, usando Ollama.

Antes de avanzar deberías poder explicar, sin mirar esta lección: qué campos pide cada credencial (Anthropic, OpenAI, Google Gemini), por qué el nodo de modelo de un proveedor nunca te deja elegir la credencial de otro, y qué es exactamente lo que queda guardado en el JSON de un workflow exportado cuando ese workflow usa una credencial.

Recursos

• Anthropic credentials — campos exactos de la credencial de Anthropic y qué nodos la usan.
• OpenAI credentials — campos de la credencial de OpenAI, incluido Organization ID.
• Google PaLM/Gemini credentials — cómo generar la key en Google AI Studio y por qué el Host no acepta proxies todavía.
• Anthropic Console — donde generas y administras tus API keys de Anthropic.
• OpenAI API keys — donde generas tu API key y ves a qué organización pertenece.
• Google AI Studio — API keys — donde generas la key de Gemini y eliges el proyecto de Google Cloud asociado.