5. Credenciales por entorno: prueba vs producción

Descripción

Al terminar esta lección vas a poder configurar las credenciales de order-triage de forma que dev y staging usen cuentas de prueba y llaves sandbox, y solo prod use las credenciales reales del CRM y del modelo de IA de Cumbre. Vas a entender la idea que hace esto posible: cómo un mismo workflow referencia la "misma" credencial —por su nombre y su tipo— aunque su valor cambie por completo entre entornos. Y vas a saber mapear las credenciales correctamente cuando importas un workflow a otro entorno, sin caer en el error clásico del identificador que no coincide.

Esto importa porque es donde el aislamiento de entornos deja de ser infraestructura y se vuelve seguridad operativa concreta. La clave de cifrado y los volúmenes separados de las lecciones anteriores fueron la pared; las credenciales son lo que esa pared protege. Si dev usara la llave real del CRM, cada prueba tocaría los datos reales de los 400 clientes de Cumbre, y todo el esfuerzo de separar entornos sería en vano. Esta lección se asegura de que lo real solo viva donde debe vivir: en prod, y en ningún otro lado.

Conexión con el módulo: esta lección es la continuación directa del Módulo 3, lección 3 ("Separar credenciales de los workflows"). Allí aprendiste que la credencial es un secreto que vive fuera del repositorio, y distinguiste la referencia (que viaja en el JSON) del valor (que jamás). Aquí ese valor se multiplica por tres: una referencia, tres valores, uno por entorno. Y se apoya en la lección 4: como cada entorno cifra con su propia N8N_ENCRYPTION_KEY, una credencial no se puede copiar cifrada de un entorno a otro —hay que recrearla—, y esta lección te enseña a hacerlo bien. La lección 6 dará el paso siguiente: sacar incluso el valor de la credencial fuera de n8n, hacia variables de entorno.

El simulador de vuelo y la cabina real

Empecemos por la imagen que ordena toda la lección.

Un piloto no aprende a volar un avión de pasajeros volando un avión de pasajeros lleno de gente. Aprende en un simulador de vuelo: una cabina que reproduce fielmente los controles reales —la misma palanca, los mismos instrumentos, el mismo tablero—, pero conectada a una computadora, no a un avión de verdad. En el simulador, el piloto puede equivocarse, estrellar el avión virtual diez veces, probar maniobras arriesgadas. Los controles son idénticos a los reales; lo que cambia es a qué están conectados. La palanca del simulador mueve un avión de mentira; la palanca de la cabina real mueve trescientas toneladas con pasajeros dentro.

Esa es exactamente la relación entre las credenciales de dev y las de prod. La credencial es la palanca. En los dos entornos, order-triage tiene una credencial llamada "Cumbre CRM key", del mismo tipo, conectada al mismo nodo, usada de la misma forma. Pero en dev, esa palanca está conectada a un CRM de prueba —un simulador, sin consecuencias—; en prod, la misma palanca está conectada al CRM real, con los datos verdaderos de los clientes. El workflow no sabe la diferencia: mueve la palanca igual. Lo que cambia no es la palanca, es a qué está conectada. Y esa conexión la decide el valor de la credencial, distinto por entorno.

La consecuencia práctica es la regla que gobierna la lección:

En dev y staging, credenciales de prueba (el simulador). En prod, credenciales reales (la cabina). Las llaves reales de Cumbre solo tocan prod.

Así, un error en order-triage que se prueba en dev estrella un avión virtual: consulta un CRM de juguete, gasta una llave de IA con límite bajo, no le pasa nada a nadie. El mismo error en prod movería datos reales. Los entornos existen para que aprendas a volar en el simulador antes de tocar la cabina.

Referencia contra valor, ahora multiplicado por entorno

Recupera la distinción del Módulo 3, porque es la llave de todo. Cuando abres el JSON de order-triage y miras el nodo que consulta el CRM, encuentras algo así:

{
  "name": "Query CRM",
  "type": "n8n-nodes-base.httpRequest",
  "credentials": {
    "httpHeaderAuth": {
      "id": "5",
      "name": "Cumbre CRM key"
    }
  }
}

Eso que ves ahí es la referencia: un puntero que dice "este nodo usa una credencial de tipo httpHeaderAuth, que se llama Cumbre CRM key". No hay ningún secreto. No aparece la llave del CRM, solo su nombre y su tipo. Esa referencia viaja en el JSON del workflow, se versiona en el repositorio, y es idéntica en los tres entornos, porque es lógica, no secreto.

El valor —la llave real— es lo que vive dentro de cada instancia de n8n, cifrado con la clave de ese entorno, y nunca en el repositorio. Aquí está la idea nueva de esta lección: la referencia es una, pero el valor es tres, uno por entorno.

	Referencia (en el JSON, versionada)	Valor (en la instancia, cifrado, secreto)
dev	Cumbre CRM key, tipo Header Auth	La llave del CRM sandbox
staging	Cumbre CRM key, tipo Header Auth	La llave del CRM de staging
prod	Cumbre CRM key, tipo Header Auth	La llave del CRM real

Lee la tabla despacio, porque es el concepto central. La columna de la referencia es idéntica en las tres filas: mismo nombre, mismo tipo. Por eso el mismo order-triage.json funciona en los tres entornos sin cambiar una línea. La columna del valor es distinta en cada fila: cada entorno tiene su propia llave, apuntando a su propio CRM. El workflow referencia "la credencial llamada Cumbre CRM key", y cada entorno resuelve ese nombre a su llave. Un nombre, tres valores.

Esto es lo que permite el sueño de "un workflow, muchos entornos". El workflow no dice "usa la llave sk-crm-live-9f2c..."; eso lo ataría a un entorno. Dice "usa la credencial llamada Cumbre CRM key", y deja que cada entorno provea su propio valor. La referencia es el enchufe estándar; el valor es lo que hay del otro lado del enchufe, distinto en cada casa.

Por qué las credenciales se recrean, no se copian

Aquí se une esta lección con la clave de cifrado de la lección 4, y resuelve una pregunta que surge naturalmente: "si order-triage necesita la credencial en los tres entornos, ¿no puedo exportarla de dev e importarla en staging y prod?".

La respuesta corta es no de la forma que imaginas, y la razón es la clave de cifrado. Recuerda: cada entorno cifra sus credenciales con su propia N8N_ENCRYPTION_KEY, distinta a propósito. Una credencial exportada de dev sale cifrada con la clave de dev. Si la importas en prod, cuyo motor usa otra clave, prod no puede descifrarla: para él es basura ilegible. La pared que construimos en la lección 4 —que aísla los secretos entre entornos— es justo lo que impide copiar la credencial cifrada.

Y aunque pudieras copiarla, no querrías: la credencial de dev tiene el valor sandbox. Copiarla a prod metería una llave de juguete en producción, donde order-triage necesita la llave real. El valor tiene que ser distinto por entorno; copiar el mismo valor a los tres derrota el propósito.

Por eso las credenciales se recrean en cada entorno, no se copian:

1. En dev, creas la credencial Cumbre CRM key con el valor sandbox.
2. En staging, creas una credencial con el mismo nombre y tipo, pero con el valor de staging.
3. En prod, creas una credencial con el mismo nombre y tipo, con el valor real.

Tres credenciales separadas, una por instancia, que comparten nombre y tipo pero no valor. Como comparten nombre y tipo, el mismo order-triage.json las referencia sin problema en los tres. Como no comparten valor, cada entorno se conecta a lo suyo. La disciplina que hace que esto funcione es una sola: el nombre y el tipo de la credencial son idénticos en los tres entornos. Si en dev se llama Cumbre CRM key y en prod la nombras CRM Prod, el workflow importado en prod no encontrará la credencial que referencia, y el nodo quedará sin conectar. El nombre es el enchufe; tiene que ser el mismo en las tres casas.

(Existe el caso legítimo de migrar una credencial en claro entre instancias con la bandera --decrypted que viste en el Módulo 3; pero eso es para mover un valor puntual por un canal seguro, no para "copiar dev a prod", y además implicaría llevar el valor equivocado. Para entornos, la vía es recrear.)

Las credenciales de order-triage, por entorno

order-triage usa dos credenciales, y las dos siguen el patrón. Veámoslas concretas:

La llave del CRM (Cumbre CRM key, tipo Header Auth). El nodo HTTP Request la usa para consultar los datos del cliente.

• En dev: apunta a un CRM sandbox —una cuenta de prueba del CRM, o un servidor de imitación—, con datos inventados. Consultar ahí no toca nada real.
• En prod: apunta al CRM real de Cumbre, con los datos de los 400 clientes.

La llave del modelo de IA (Cumbre LLM key). El nodo AI Agent la usa para clasificar el pedido.

• En dev: una llave con límite de gasto bajo, o —mejor aún, y es lo que hace este stack— un modelo local de Ollama, que no cuesta nada. Recuerda que el Starter Kit trae Ollama justo para esto; el Módulo 5 lo explota a fondo para probar workflows con IA a costo cero.
• En prod: la llave del proveedor de modelos que Cumbre use de verdad, con el modelo de calidad de producción.

Fíjate en la ventaja de tener modelos locales en dev: no solo evitas tocar datos reales, sino que evitas gastar dinero real probando. Una prueba de order-triage en dev que clasifica cien pedidos inventados con un modelo local de Ollama cuesta cero. La misma prueba contra un proveedor de pago costaría dinero por cada pedido. El aislamiento de entornos, aquí, también es aislamiento de costos.

El caso especial de staging: prueba, pero parecido a lo real

Entre dev y prod está staging, y sus credenciales merecen una nota, porque no son ni las de uno ni las del otro. La regla general —"prueba en dev y staging, real solo en prod"— es correcta, pero staging tiene un matiz: sus credenciales de prueba deben apuntar a algo lo más parecido posible a producción, sin ser producción.

Piénsalo así. En dev, la credencial del CRM puede apuntar a un CRM de juguete cualquiera, o incluso a un servidor de imitación que devuelve respuestas inventadas; ahí solo importa que la lógica del workflow corra. En staging, en cambio, quieres que la credencial apunte a un CRM sandbox del mismo proveedor que el real, con la misma forma de respuestas, los mismos códigos de error, las mismas peculiaridades. Muchos servicios ofrecen justo esto: una cuenta o un modo sandbox que se comporta como el real pero sin efectos reales. Esa es la credencial ideal para staging.

¿Por qué esta distinción? Porque el trabajo de staging es cazar los errores que solo aparecen contra un sistema que se comporta como el real. Si staging usara un CRM de juguete demasiado distinto del real, dejaría pasar esos errores hasta prod, y perdería su razón de ser. Cuanto más se parezca la credencial de staging a la de prod —mismo proveedor, modo sandbox—, mejor cumple su función de último filtro.

Así, la escala completa de las credenciales de order-triage queda:

• dev: lo más barato y aislado posible —CRM de juguete o imitación, modelo local de Ollama—. Objetivo: que la lógica corra.
• staging: de prueba, pero del mismo tipo que producción —CRM sandbox del proveedor real, un modelo de calidad parecida—. Objetivo: confiar en que funcionará en prod.
• prod: lo real —CRM real, modelo de producción—. Objetivo: correr de verdad.

No siempre vas a poder tener un sandbox perfecto para staging, y está bien: es un ideal al que te acercas según lo que el proveedor ofrezca. Lo innegociable sigue siendo lo mismo —las llaves reales solo en prod—; el matiz de staging es cómo hacer que su prueba sea lo más fiel posible sin cruzar esa línea.

Ejemplo trabajado: crear la credencial en dos entornos e importar el workflow

Vamos a recorrer el flujo concreto: crear Cumbre CRM key en dev con valor sandbox, importarlo también en prod con valor real, y conectar el workflow importado. Recuerda: tú haces esto en tus instancias de n8n; la guía no ejecuta nada.

Paso 1 — Levanta dev y crea la credencial sandbox. Con dev corriendo en http://localhost:5678, entra al editor, ve a la sección de credenciales, y crea una nueva de tipo Header Auth. Nómbrala exactamente Cumbre CRM key. En el valor, pon la llave del CRM sandbox (por ejemplo, un token de una cuenta de prueba: Bearer sk-crm-sandbox-1a2b3c).

Qué esperar: n8n cifra ese valor con la N8N_ENCRYPTION_KEY de dev y lo guarda en la base de datos de dev. La credencial ahora existe en dev, y solo en dev.

Paso 2 — Importa order-triage en dev y conéctalo. Importa el order-triage.json de tu repositorio. Cuando el nodo HTTP Request busque la credencial Cumbre CRM key, la va a encontrar —porque acabas de crearla con ese nombre exacto— y se conectará sola. Qué esperar: el nodo muestra la credencial conectada, sin advertencias. Si el nombre no coincidiera, el nodo mostraría la credencial como faltante.

Paso 3 — Levanta prod y repite con el valor real. Con prod corriendo en http://localhost:5680 (otra instancia, otra base de datos, otra clave de cifrado), entra a su editor y crea una credencial de tipo Header Auth, nombrada exactamente igual: Cumbre CRM key. Pero en el valor, pon la llave del CRM real (Bearer sk-crm-live-9f2c8a1b).

Qué esperar: ahora existen dos credenciales Cumbre CRM key —una en dev con valor sandbox, una en prod con valor real—, en dos instancias separadas, cifradas con claves distintas. Ninguna de las dos sabe de la otra.

Paso 4 — Importa order-triage en prod y verifica la conexión. Importa el mismo order-triage.json en prod. El nodo HTTP Request busca Cumbre CRM key, la encuentra en prod —con su valor real—, y se conecta. Qué esperar: el mismo workflow, sin un solo cambio en su JSON, corriendo en prod contra el CRM real. La magia no fue cambiar el workflow; fue que cada entorno tenía su propia credencial con el mismo nombre.

Paso 5 — Confirma que no cruzaste valores. El chequeo mental que cierra el flujo: ¿la credencial de prod tiene el valor real, y la de dev el sandbox? Nunca al revés. Si por descuido pusiste el valor real en dev, cada prueba en dev estaría tocando el CRM real —el accidente que todo esto busca evitar—. Revisa que lo real viva solo en prod.

Leer es incómodo; escribir es un desastre

Hay un matiz sobre las credenciales de prueba que conviene entender, porque explica por qué la regla "sandbox en dev" es tan estricta. No todas las operaciones contra un sistema externo son igual de peligrosas cuando usas la credencial equivocada.

order-triage hace dos tipos de cosas contra el CRM. Puede leer —consultar los datos de un cliente para enriquecer el pedido— y, según cómo esté armado, puede escribir —registrar el resultado del pedido, actualizar un estado, crear un registro—. La diferencia entre las dos, cuando por accidente corren contra el sistema real desde dev, es enorme:

• Una lectura equivocada es incómoda pero reversible. Si dev consulta el CRM real por error, viste datos reales que no debías, lo cual es un problema de privacidad, pero no cambiaste nada. El CRM sigue igual.
• Una escritura equivocada es un desastre y muchas veces irreversible. Si dev escribe en el CRM real —registra un pedido de prueba, cambia el estado de un cliente real, manda un correo real—, alteraste datos de producción con basura de prueba. Limpiar eso va de difícil a imposible: un correo enviado no se des-envía, un pedido registrado en el sistema de facturación ya disparó procesos.

Por eso la credencial de dev no solo debe apuntar a un sistema de prueba: idealmente debe ser una credencial que ni siquiera pueda tocar producción. Una llave sandbox que solo funciona contra el CRM de prueba es más segura que una llave real "que prometo usar con cuidado", porque la sandbox hace imposible el accidente de escritura, en vez de dejarlo a tu memoria.

Este es un argumento más a favor de los modelos locales para la parte de IA en dev: un modelo de Ollama corriendo en tu máquina no puede, por construcción, gastar dinero real ni tocar la cuenta de producción del proveedor. La imposibilidad física es mejor garantía que la disciplina. Cuando puedas elegir entre "una credencial de prueba que no puede tocar lo real" y "la credencial real usada con cuidado", elige siempre la primera. El módulo entero se trata de hacer los accidentes imposibles, no improbables.

El error del identificador que no coincide

Hay un detalle técnico del Módulo 1 (lección 5, "qué se rompe al reimportar") que reaparece aquí y conviene enfrentar de una vez, porque es la fuente número uno de credenciales "faltantes" al importar entre entornos.

Recuerda que la referencia en el JSON tiene dos partes: un id y un name.

"credentials": {
  "httpHeaderAuth": { "id": "5", "name": "Cumbre CRM key" }
}

El id —aquí "5"— es el identificador que la credencial tenía en la instancia donde se exportó el workflow (digamos, dev). Pero cuando creas la credencial Cumbre CRM key en prod, prod le asigna su propio id —quizás "2", quizás "11"—, porque los identificadores son locales a cada instancia. Así que el id del JSON ("5", de dev) no coincide con el id de la credencial en prod.

¿Qué pasa entonces al importar? Depende de la versión de n8n, y por eso conviene saberlo y verificarlo:

• En el mejor caso, n8n reconcilia por nombre: ve que el id no existe en prod pero hay una credencial con el name Cumbre CRM key, y la conecta. Por eso la disciplina del nombre idéntico es tan importante: es lo que salva la reconexión.
• En otros casos, el nodo aparece con la credencial marcada como faltante, y tienes que abrirlo y seleccionar a mano la credencial correcta del entorno. Es un clic, no un drama, pero hay que hacerlo, y hay que saber que puede pasar.

La regla práctica que evita el 90% del dolor: nombra las credenciales igual en todos los entornos, para que la reconciliación por nombre funcione. Y cuando importes un workflow a un entorno nuevo, revisa cada nodo con credencial y confirma que quedó conectado a la credencial correcta de ese entorno, no marcado como faltante ni —peor— conectado por casualidad a otra. Ese repaso de treinta segundos al importar es lo que separa una promoción limpia de un "funcionaba en dev y en prod da 401".

Un detalle que tranquiliza sobre este repaso: reconectar una credencial faltante es un clic, no una reconstrucción. Cuando un nodo muestra su credencial en blanco, abres el nodo, despliegas el selector de credencial, y eliges de la lista la que ya creaste en ese entorno con el nombre correcto. n8n reescribe la referencia con el id local, y el nodo queda conectado. No pierdes nada del workflow; solo le vuelves a decir cuál de las credenciales de este entorno usar. Por eso la disciplina del nombre idéntico paga doble: cuando la reconciliación automática falla, tú encuentras la credencial correcta en la lista al instante, porque se llama como esperas. Si cada entorno nombrara sus credenciales distinto, ese clic se volvería una cacería.

Y una nota de flujo para cuando promuevas de verdad (Módulo 6): este repaso de credenciales es un paso fijo del proceso de llevar un workflow a un entorno nuevo, no un accidente. La primera vez que un workflow llega a un entorno, sus credenciales se mapean; las veces siguientes, si los nombres no cambiaron, la reconexión es automática o trivial. Vale la pena convertirlo en un hábito —"importé, ahora reviso los nodos con credencial"— para que nunca se te escape.

Errores comunes

Poner la credencial real en dev (práctico, y anula todo el módulo). Qué pasa: alguien, por prisa o por copiar, crea la credencial Cumbre CRM key en dev con la llave real del CRM. Desde ese momento, cada prueba en dev consulta el CRM real, y cualquier operación de escritura que el workflow haga toca datos reales. El "cuarto acolchonado" dejó de estarlo. Por qué pasa: es más fácil copiar la llave que ya se tiene que conseguir una sandbox. Cómo detectarlo: mira el valor de las credenciales de dev; si contienen -live- o apuntan al dominio real del CRM, hay una llave real donde no debe. Cómo corregirlo: la llave real vive solo en prod. Consigue una cuenta o llave sandbox para dev y staging, o usa un modelo local para la parte de IA. Y si ya probaste con la real, revisa qué tocó y, si expusiste la llave, rótala.

Nombrar la credencial distinto en cada entorno (práctico). Qué pasa: alguien crea Cumbre CRM key en dev, CRM Staging en staging y CRM Prod en prod. Al importar el mismo order-triage.json, la reconciliación por nombre falla en staging y prod, y los nodos aparecen con credenciales faltantes. Por qué pasa: parece natural "identificar" el entorno en el nombre de la credencial. Cómo detectarlo: si tus credenciales tienen el entorno en el nombre, y al importar un workflow los nodos salen desconectados, es esto. Cómo corregirlo: nombre y tipo idénticos en los tres entornos; lo que identifica al entorno no es el nombre de la credencial, es en qué instancia vive. El nombre es el enchufe estándar; ponerle el entorno lo vuelve un enchufe distinto por casa.

Intentar exportar la credencial de un entorno e importarla cifrada en otro (conceptual). Qué pasa: alguien exporta la credencial de dev (cifrada) e intenta importarla en prod, esperando que "se copie". prod no la puede descifrar, porque su clave es distinta, y además tendría el valor equivocado. Por qué pasa: parece más rápido copiar que recrear. Cómo detectarlo: credenciales que aparecen pero fallan al usarse, o errores de descifrado tras un import entre entornos. Cómo corregirlo: no se copia, se recrea: crea la credencial en cada entorno con el mismo nombre y tipo pero el valor de ese entorno. La clave de cifrado distinta por entorno hace que copiar cifrado no funcione, y es a propósito.

No revisar los nodos después de importar (práctico). Qué pasa: alguien importa order-triage en prod, ve que "se importó bien", y lo activa sin abrir los nodos. Uno de ellos quedó con la credencial marcada como faltante, y el workflow falla en la primera ejecución real con un 401. Por qué pasa: el import "termina" y se asume que todo quedó conectado. Cómo detectarlo: nodos con un ícono de advertencia o la credencial en blanco tras importar. Cómo corregirlo: haz el repaso de treinta segundos —abre cada nodo con credencial y confirma que está conectado a la credencial correcta de ese entorno— antes de activar. Es la diferencia entre descubrir el problema tú, en calma, y descubrirlo en la primera ejecución real.

Ejercicios

Ejercicio 1 — Referencia o valor. Para cada elemento, di si es referencia (viaja en el JSON, igual en los tres entornos) o valor (vive en la instancia, distinto por entorno, secreto): (a) el texto "name": "Cumbre CRM key" dentro del JSON del workflow; (b) la cadena Bearer sk-crm-live-9f2c8a1b; (c) el tipo httpHeaderAuth del nodo; (d) la llave sandbox del CRM que creaste en dev; (e) el id "5" en el bloque de credenciales del JSON.

Ver solución

(a) Referencia. El nombre de la credencial viaja en el JSON y es igual en los tres entornos; no es secreto.

(b) Valor. Es la llave real del CRM: un secreto, que vive solo en la instancia de prod, cifrado, y jamás en el repo.

(c) Referencia. El tipo de la credencial es parte de la lógica del nodo; igual en los tres entornos.

(d) Valor. La llave sandbox es el secreto que vive en la instancia de dev, distinto del de prod.

(e) Referencia (con un matiz). El id viaja en el JSON, pero es un identificador local de la instancia donde se exportó, así que puede no coincidir en otro entorno; por eso la reconexión se apoya en el name, no en el id.

Por qué funciona: si separaste bien las cinco, tienes clara la línea que hace posible "un workflow, muchos entornos" —la referencia es común y se versiona; el valor es por entorno y es secreto—. El matiz del id (e) es justo lo que explica por qué a veces los nodos salen desconectados al importar.

Ejercicio 2 — Diseña la tabla de credenciales de order-triage. order-triage usa dos credenciales: Cumbre CRM key (Header Auth) y Cumbre LLM key (modelo de IA). Dibuja una tabla con una fila por credencial y una columna por entorno (dev, staging, prod), y en cada celda escribe qué valor tendría (no la llave literal, sino su naturaleza: sandbox, límite bajo, real, local, etc.). Después señala qué celdas contienen algo que jamás debe salir de su instancia.

Ver solución

Credencial	dev	staging	prod
Cumbre CRM key	CRM sandbox (datos inventados)	CRM de staging (datos parecidos a los reales, sin consecuencias)	CRM real (datos de los 400 clientes)
Cumbre LLM key	Modelo local de Ollama (costo cero) o llave con límite bajo	Llave con límite bajo o modelo local	Llave del proveedor real, modelo de producción

Las celdas que contienen algo que jamás debe salir de su instancia son las de la columna prod: la llave real del CRM y la llave real del proveedor de IA. Esas son las que, si se filtran, dan acceso a datos reales y generan gasto real. Las de dev y staging son de menor riesgo por diseño (sandbox, límite bajo, local), pero igual son secretos y no van al repo.

Por qué funciona: llenar la tabla te obliga a decidir, credencial por credencial y entorno por entorno, qué es real y qué es de prueba. Ese ejercicio explícito es lo que evita el error más caro —una llave real en dev—: si lo pensaste de antemano, no lo pones por descuido.

Ejercicio 3 — Diagnostica el import roto. Un compañero importó order-triage en prod y te dice: "Se importó, pero cuando lo ejecuto el nodo del CRM da 401 no autorizado. En dev funciona perfecto." Le pides que abra el nodo HTTP Request en prod. ¿Cuáles son las dos causas más probables, y cómo distingues una de la otra?

Ver solución

Las dos causas más probables:

1. La credencial quedó marcada como faltante o desconectada. Al importar, el id del JSON (de dev) no coincidió con ningún id de prod, y la reconciliación por nombre no ocurrió (quizás porque la credencial en prod se llama distinto, o no se creó). El nodo no tiene credencial, y por eso el CRM responde 401. Cómo lo distingues: al abrir el nodo, la credencial aparece en blanco o con una advertencia.

2. La credencial está conectada, pero su valor es incorrecto. La credencial Cumbre CRM key existe en prod y está conectada, pero se creó con un valor equivocado —por ejemplo, se copió el token sandbox de dev, que el CRM real no reconoce—. Cómo lo distingues: al abrir el nodo, la credencial aparece conectada, pero al probar la llamada el CRM real rechaza el token.

La forma de distinguir: abre el nodo. Si la credencial está en blanco/faltante, es la causa 1 —créala o selecciónala en prod—. Si está conectada pero falla, es la causa 2 —revisa que su valor sea la llave real de prod, no una copiada de dev—.

Por qué funciona: el 401 tiene dos orígenes que se arreglan distinto (falta la credencial vs. la credencial tiene el valor equivocado), y saber cuál es antes de tocar nada te ahorra dar palos de ciego. Es exactamente el tipo de diagnóstico que hace un dueño del sistema.

Resumen y siguiente paso

En esta lección hiciste concretas las credenciales por entorno. Con la imagen del simulador de vuelo y la cabina real grabaste la regla que gobierna todo: credenciales de prueba en dev y staging —el simulador—, credenciales reales solo en prod —la cabina—, y las llaves reales de Cumbre nunca tocan otro entorno. Entendiste que la referencia de una credencial (su nombre y tipo) viaja en el JSON y es idéntica en los tres entornos, mientras que su valor vive en cada instancia y es distinto por entorno: una referencia, tres valores. Viste por qué las credenciales se recrean en cada entorno en vez de copiarse —porque cada entorno cifra con su propia clave y porque el valor debe ser distinto—, con la disciplina única de mantener el nombre y el tipo idénticos en los tres para que el mismo workflow las referencie. Recorriste el flujo de crear la credencial con valor sandbox en dev y real en prod, importar el mismo order-triage.json en ambos, y enfrentaste el error del identificador que no coincide, que se resuelve reconciliando por nombre y revisando cada nodo al importar.

Antes de avanzar deberías poder: explicar la diferencia entre la referencia y el valor de una credencial y por qué eso permite un workflow para tres entornos; decir por qué las credenciales se recrean y no se copian; y describir qué revisar en los nodos después de importar un workflow a otro entorno.

La lección 6 da un paso más en la misma dirección: sacar los secretos incluso de la interfaz de n8n. Vas a conocer la expresión $env, que deja que un nodo lea una variable del entorno —de ese .env que ya configuraste—, y las Variables de n8n; vas a entender por qué los secretos deben vivir en el gestor del entorno y nunca escritos dentro del workflow; y vas a ver, con honestidad de planes, qué ofrecen los secretos externos (Vault, AWS, GCP) como feature Enterprise y cuál es la alternativa equivalente en Community usando variables de entorno.

Recursos

• Credentials — n8n Docs — cómo se crean y administran las credenciales en n8n y cómo un nodo las referencia por tipo y nombre.
• Import and export credentials — n8n Docs — la referencia de export:credentials/import:credentials y la bandera --decrypted, para el caso puntual de migrar un valor entre instancias.
• Set a custom encryption key — n8n Docs — por qué una credencial cifrada con la clave de un entorno no se descifra en otro, la base de "recrear, no copiar".
• HTTP Request node — n8n Docs — el nodo que consulta el CRM en order-triage y cómo se le asocia una credencial de tipo Header Auth.