2. Cuentas de prueba y llaves sandbox

Descripción

Al terminar esta lección vas a poder conseguir y usar una cuenta de prueba y una llave sandbox de un proveedor externo —el CRM, una pasarela de pagos, una API de correo— para que tu workflow le hable a un servicio real en su modo de prueba, sin tocar los datos ni el dinero de producción. Vas a saber distinguir una llave de prueba de una de producción de un vistazo, vas a enganchar cada tipo de llave con las credenciales por entorno que montaste en el Módulo 4, y vas a tener una regla clara —una lista corta y dura— de qué cosas no se prueban jamás directamente contra producción, pase lo que pase.

Esto importa porque es el primer punto del checklist de pre-producción y el que hace posibles a todos los demás. Si tu prueba le pega al CRM real, no hay datos sintéticos ni aserciones que te salven: ya ensuciaste producción. La llave sandbox es la que convierte tu instancia de dev de "un lugar donde corro cosas" a "un lugar donde corro cosas sin consecuencias reales". Es la frontera entre el cajón de arena y el mundo.

Conexión con el módulo: en la lección 1 viste que probar contra producción tiene tres costos —datos, dinero, reputación—. Esta lección ataca el primero y el tercero de raíz: con una llave sandbox, el nodo HTTP Request de order-triage le escribe a un CRM de prueba, no al real, así que ensuciar datos y mandar efectos al mundo dejan de ser posibles por diseño. Se apoya de lleno en el Módulo 4: allí aprendiste a tener una credencial distinta por entorno; aquí le damos su contenido —llave de prueba en dev/staging, llave real solo en prod—. La lección 3 le pone las entradas (datos sintéticos) al workflow que esta lección ya conectó a un destino seguro.

La casa modelo y el dinero de Monopoly

Piensa en una constructora que quiere vender departamentos de un edificio que todavía no termina. No lleva a los clientes al departamento de verdad —está en obra, es peligroso, y cada visita lo ensucia—. Construye una casa modelo: una réplica idéntica, con los mismos acabados, los mismos muebles, la misma distribución, pero que no es donde nadie va a vivir. El cliente la recorre, abre las llaves, prende las luces, se hace una idea completa de cómo será su departamento. Todo se siente real. Y sin embargo, si tropieza y rompe un jarrón de la casa modelo, se repone un jarrón de utilería; no se dañó el hogar de nadie.

Una cuenta de prueba es la casa modelo de un servicio. El proveedor —digamos, el CRM que usa Cumbre— te da una cuenta separada que funciona igual que la real: tiene la misma API, responde igual, se comporta igual. Pero sus datos son de utilería. Los "clientes" que viven ahí son inventados. Si tu workflow crea, modifica o borra registros en la cuenta de prueba, toca utilería, no la operación de Cumbre. Recorres el sistema completo, con realismo total, sin poder romper nada que importe.

Y la llave sandbox —o llave de prueba, o test key, o sandbox API key; son sinónimos— es la llave que abre la casa modelo en vez de la casa real. Una llave de API (API key) es una credencial: un texto secreto, largo, que tu workflow le manda al proveedor para identificarse, como una contraseña que dice "soy Cumbre, déjame entrar". Los proveedores serios te dan dos llaves distintas para la misma cuenta:

• La llave de producción (live key) abre la casa real. Las acciones que haces con ella son de verdad: el cobro se cobra, el correo se manda, el registro entra al CRM que ve todo el equipo.
• La llave de prueba (test key / sandbox key) abre la casa modelo. Las acciones se ven y responden igual, pero no producen efectos reales: el "cobro" es de mentira, el "correo" no le llega a nadie, el registro entra a un CRM de prueba que puedes vaciar cuando quieras.

La misma llamada de tu workflow, la misma API, el mismo código. Lo único que cambia es cuál de las dos llaves usas. Y esa única diferencia decide si estás jugando en el cajón de arena o en producción.

Hay una imagen aún más simple para la llave de prueba: es dinero de Monopoly. Cuando el nodo AI Agent llama a un modelo de lenguaje o el nodo HTTP le pega a una pasarela de pagos en modo de prueba, las transacciones se procesan de punta a punta —la pasarela responde "cobro aprobado", te devuelve un identificador, todo el flujo funciona— pero con billetes de juguete. Nadie pierde ni gana un peso real. Puedes "cobrar" mil veces para probar, y a fin de mes la factura es cero.

Ejemplo trabajado: el test mode de una pasarela de pagos

Para ver el patrón concreto, tomemos el caso más estandarizado del mercado: el test mode (modo de prueba) de una pasarela de pagos como Stripe. order-triage hoy no cobra, pero este ejemplo es el más limpio para entender el mecanismo, y lo vas a reconocer en cualquier proveedor serio.

Una pasarela de pagos en modo de prueba te da, típicamente:

Un par de llaves marcadas. Una llave de prueba y una de producción, y la clave del asunto: están marcadas en el propio texto para que las distingas de un vistazo. En Stripe, por ejemplo, las llaves secretas de prueba empiezan con sk_test_ y las de producción con sk_live_. La palabra test o live viene incrustada en la credencial misma. No es casualidad: el proveedor sabe que confundirlas es el error más caro que puedes cometer, así que lo hace visible.

sk_test_51H8xY2eZvKY...    ← llave de prueba: el "test" te avisa. Cajón de arena.
sk_live_51H8xY2eZvKY...    ← llave de producción: el "live" te avisa. Dinero real.

Tarjetas de prueba que no existen. Para probar un cobro sin una tarjeta real, la pasarela publica números de tarjeta de prueba. El más conocido de Stripe es 4242 4242 4242 4242: en modo de prueba, ese número simula un cobro exitoso; en modo producción, es una tarjeta inválida que no cobra nada. Hay otros números para simular casos difíciles —tarjeta rechazada, fondos insuficientes, error de red—, justo los casos borde que la lección 3 te va a enseñar a incluir.

Un panel separado. Los cobros de prueba aparecen en una vista de prueba del panel, apartados de los cobros reales, para que nunca los confundas al revisar.

Qué esperar al usarlo. Configuras el nodo HTTP Request (o el nodo de la pasarela, si existe) con la llave sk_test_..., le mandas la tarjeta 4242..., y corres el workflow. La pasarela responde exactamente como respondería en producción: un 200 OK, un identificador de cobro, un estado "succeeded". Todo el flujo posterior de tu workflow corre con datos realistas. Y sin embargo no se movió un solo peso, no hay una tarjeta real involucrada, y puedes repetirlo cuantas veces quieras. Eso es una prueba a costo cero contra un servicio real.

Un aviso de higiene, porque los detalles envejecen: el prefijo exacto (sk_test_), el número de tarjeta (4242...) y el nombre del modo (test mode) son de Stripe y ciertos al momento de escribir esta guía (2026). Otro proveedor los llama distinto, y hasta Stripe puede cambiarlos. La idea es universal —dos llaves marcadas, datos de prueba, panel separado—; los nombres exactos, verifícalos siempre en la doc del proveedor que uses. Este es el mismo hábito de "verifica contra tu propia versión" que traes de los módulos anteriores.

El CRM de Cumbre: cuenta sandbox y llave de prueba

Bajemos el patrón a order-triage. La pieza que nos importa es el nodo HTTP Request que le escribe al CRM: es el efecto secundario que no queremos disparar contra producción al probar.

El proveedor del CRM de Cumbre —como casi cualquier CRM serio— ofrece alguna forma de entorno de prueba. En la práctica te vas a topar con una de estas tres modalidades, y conviene que las conozcas porque cambian cómo configuras la credencial:

Modalidad A: una cuenta sandbox separada. El proveedor te da una segunda cuenta, aparte de la de producción, pensada para desarrollo. Tiene su propia URL base (por ejemplo https://sandbox-api.crm.example.com en vez de https://api.crm.example.com) y sus propias llaves. Es la separación más limpia: la cuenta de prueba y la real ni se ven entre sí. Es lo que ofrecen los CRM grandes, a veces con nombre de "developer account" o "sandbox environment".

Modalidad B: una llave de prueba dentro de la misma cuenta. El proveedor no separa las cuentas, pero te da una llave marcada como de prueba (igual que el sk_test_ de la pasarela) que, dentro de la misma cuenta, opera sobre un espacio de datos de prueba. Menos limpia que la A, pero suficiente.

Modalidad C: no hay modo de prueba nativo. Algunos proveedores —sobre todo los más pequeños o las APIs internas de una empresa— simplemente no ofrecen sandbox. Aquí no te queda una llave mágica: tienes que crear tu propia separación, y esa es justo la lección 4 (proteger el efecto secundario para que no se dispare) combinada con una cuenta de prueba que armes a mano dentro del mismo sistema. Es el caso más incómodo y el más común en el mundo real, así que no te sorprendas si te toca.

Para el hilo de la guía, supongamos que el CRM de Cumbre está en la modalidad A: hay una cuenta sandbox con su URL base y su llave de prueba. Lo que sigue es cómo conectas esa llave sin que se te cruce jamás con la de producción, y ahí es donde el Módulo 4 hace todo el trabajo pesado.

Enganchar la llave con las credenciales por entorno

Aquí está el corazón de la lección, y es donde se junta con lo que ya construiste. En el Módulo 4 aprendiste a que cada entorno tenga su propia credencial, y que el workflow no guarde la llave adentro sino una referencia a una credencial que se resuelve en cada instancia. Recordemos la idea rápido, porque es la que hace que esto funcione.

order-triage no lleva la llave del CRM incrustada en el nodo HTTP. Lleva una referencia a una credencial que se llama, digamos, CRM API. Cada una de tus tres instancias de n8n tiene una credencial con ese mismo nombre, pero con contenido distinto:

Instancia	Credencial CRM API contiene	URL base	Efecto de una llamada
dev	La llave sandbox del CRM	https://sandbox-api.crm.example.com	Escribe en el CRM de prueba. Reversible.
staging	La llave sandbox del CRM	https://sandbox-api.crm.example.com	Escribe en el CRM de prueba. Reversible.
prod	La llave de producción del CRM	https://api.crm.example.com	Escribe en el CRM real. Definitivo.

Fíjate en lo elegante del arreglo: el workflow es idéntico en los tres entornos. El mismo JSON de order-triage, byte por byte, corre en dev, en staging y en prod. No hay un "workflow de prueba" y un "workflow de producción" —eso sería tener dos versiones que se desincronizan, justo el problema que el Módulo 1 te enseñó a odiar—. Hay un workflow que referencia una credencial CRM API, y es el entorno el que decide si esa credencial apunta al cajón de arena o al mundo. Cambias de entorno, cambias de destino, sin tocar una sola línea del workflow.

Esto tiene una consecuencia que vale la pena subrayar: probar en sandbox no es modificar el workflow, es correrlo en el entorno correcto. El error de principiante es hacer una copia del workflow, cambiarle la llave a mano para que apunte a prueba, y probar sobre esa copia. Funciona una vez y después se pudre: la copia y el original se separan, pruebas sobre uno y promueves el otro, y el día que difieren ya no probaste lo que promoviste. El arreglo del Módulo 4 evita eso entero: pruebas el mismo artefacto que vas a promover, solo que en un entorno donde sus efectos son de utilería.

Cómo se ve en la credencial

Concretamente, en tu instancia de dev, la credencial CRM API del nodo HTTP se ve más o menos así (los nombres exactos de los campos dependen del tipo de credencial que uses —una credencial de "Header Auth", una de "API Key", una genérica—; verifícalos en tu panel):

Nombre de la credencial:  CRM API
URL base:                 https://sandbox-api.crm.example.com
Header:                   Authorization: Bearer crm_test_a1b2c3d4...
                                                 ^^^^ la marca "test" te avisa

Y en prod, la credencial con el mismo nombre contiene:

Nombre de la credencial:  CRM API
URL base:                 https://api.crm.example.com
Header:                   Authorization: Bearer crm_live_z9y8x7w6...
                                                 ^^^^ la marca "live": dinero de verdad

Qué esperar: cuando corres order-triage en dev, el nodo HTTP toma la credencial CRM API de esa instancia —la que tiene la llave crm_test_— y le pega al sandbox. Ves en la salida del nodo una respuesta real del CRM de prueba: un 201 Created, un identificador de registro. Vas al panel del CRM sandbox y ahí está tu registro de prueba. Vas al CRM de producción y no hay nada nuevo. Esa es la señal de que la separación funciona: la acción ocurrió, fue real y verificable, y cayó del lado seguro.

La prueba de humo de la credencial: verifica el destino antes de confiar

Antes de correr una prueba de verdad, hay un chequeo de treinta segundos que vale la pena volver un reflejo, sobre todo la primera vez que configuras una credencial nueva: confirma a dónde apunta, con una acción que no ensucie nada. Una llave marcada test debería ir al sandbox, pero un dedo distraído pudo copiar la URL base equivocada, o la llave y la URL pudieron quedar cruzadas. No lo des por hecho: pruébalo.

La forma segura es correr una acción de solo lectura primero —listar registros, consultar un cliente— y mirar qué te devuelve. Si el CRM sandbox tiene tres clientes de utilería con nombres como "Café Prueba" y tu lectura te devuelve esos tres, estás apuntando al cajón de arena. Si te devuelve los nombres reales de las cafeterías de Cumbre, detente: estás apuntando a producción, y una llave test que devuelve datos reales significa que algo está mal configurado. Lo mismo con una acción reversible: crea un registro de prueba, verifica que aparezca en el panel del sandbox y no en el de producción, y bórralo.

Es el mismo espíritu del ejemplo trabajado, ahora como hábito: nunca corras un efecto secundario contra una credencial cuya casa —modelo o real— no confirmaste. Treinta segundos de lectura te ahorran el peor error de la lección 2.

Una honestidad sobre los sandboxes: la casa modelo no es la casa

Vale la pena decir algo que casi ninguna guía admite: un sandbox es una casa modelo, y una casa modelo no es idéntica a la casa donde vas a vivir. Se parece muchísimo, lo suficiente para probar casi todo, pero tiene diferencias que conviene tener en la cabeza, para que ninguna te sorprenda el día de la promoción.

El sandbox a veces se comporta distinto que producción. Algunos proveedores mantienen su entorno de prueba con una versión ligeramente atrasada de la API, o con algunas funciones deshabilitadas, o con límites de uso distintos. Un cobro de prueba siempre "aprueba" con la tarjeta 4242..., pero en producción una tarjeta real puede rechazarse por mil razones que el sandbox no simula. Un CRM sandbox puede aceptar un registro que el de producción rechazaría por una validación que solo existe en real.

El sandbox suele tener menos datos y menos carga. En prueba tienes tres clientes de utilería; en producción, cientos. Un workflow que funciona con tres registros puede toparse en producción con paginación, con tiempos de respuesta más largos, o con un cliente cuyo nombre tiene un carácter que rompe tu parseo. El sandbox no te muestra la escala real.

Esto no es un argumento para probar contra producción —sería tirar el bebé con el agua—. Es el argumento para el segundo peldaño que ya construiste en el Módulo 4: staging. La razón de existir de staging es exactamente esta grieta. dev es la casa modelo lejos de la obra, donde iteras rápido y rompes sin miedo. staging es la casa modelo construida al lado de la real, con los mismos materiales y lo más parecida posible a producción —los mismos volúmenes de datos que puedas, la configuración más cercana—, para cazar justo las diferencias que un sandbox de juguete esconde. Por eso en la tabla de arriba staging también usa la llave sandbox, pero se piensa como "el ensayo general", no como "el borrador".

La regla práctica que sale de aquí: iteras en dev, ensayas en staging, y aun así la primera corrida en prod la vigilas de cerca. El sandbox reduce el riesgo enormemente; no lo lleva a cero. Saberlo te ahorra la falsa confianza de "pasó en sandbox, entonces es imposible que falle en producción" —que es una versión más sofisticada del "corrió una vez y salió bien" de la lección 1—.

Qué NUNCA se prueba directamente contra producción

Hay una lista corta de acciones que no se prueban contra producción jamás, ni "una vez para ver", ni "con cuidado", ni "es un cambio chico". No es una recomendación de estilo; es una regla dura, porque estas acciones comparten una propiedad: no tienen deshacer. Una vez que ocurren en producción, ocurrieron.

1. Cobrar dinero. Un cargo a una tarjeta real es real. Aunque lo reembolses, quedó el movimiento, quizás una comisión, quizás una notificación al cliente. Los cobros se prueban siempre con la llave de prueba y las tarjetas de prueba de la pasarela. Nunca con una tarjeta real, ni la tuya.

2. Mandar mensajes a personas reales. Un correo, un SMS, un WhatsApp, un mensaje de Slack a un canal real: una vez enviado, le llegó a alguien. No hay recall. Los envíos se prueban contra una cuenta de correo de prueba, un número propio, o un canal de sandbox —nunca contra la lista de clientes de la empresa—. Este es el que más rápido daña la reputación: un correo de prueba con texto de relleno que le llega a las 400 cafeterías de Cumbre es un incidente que se cuenta durante meses.

3. Escribir o borrar en la base de datos de producción. Crear, modificar o eliminar registros reales —clientes, pedidos, inventario— contamina o destruye datos de los que depende la operación. Un DELETE mal apuntado no se deshace. Se prueba contra la cuenta sandbox o una base de datos de prueba.

4. Disparar acciones en sistemas de terceros irreversibles. Publicar un post, emitir una factura fiscal, generar una orden de compra a un proveedor, mover dinero entre cuentas. Todo lo que, una vez hecho, sale de tu control.

La regla para reconocerlos es una sola pregunta: "si esto se ejecuta por error, ¿puedo deshacerlo sin que nadie se entere?" Si la respuesta es no —porque le llegó a alguien, movió dinero, o borró algo—, entonces es una acción que no se prueba contra producción, y punto. Cuando el proveedor te da un modo de prueba, lo usas. Cuando no te lo da (la modalidad C de arriba), tu obligación es construir la protección tú mismo, y eso es exactamente lo que resuelve la lección 4: proteger el efecto secundario para que, en modo prueba, ni siquiera se intente.

Fíjate en que las tres primeras son justo los tres costos de la lección 1: dinero (cobrar), reputación (mandar mensajes), datos (escribir/borrar). La lista no es nueva; es la misma amenaza, vista ahora como una regla operativa de "qué no hacer".

Errores comunes

Confundir la llave de prueba con la de producción (práctico y caro). Qué pasa: alguien copia la llave equivocada en la credencial —pone la live donde iba la test— y su "prueba" en dev termina cobrando de verdad o escribiendo en el CRM real. Por qué pasa: las dos llaves se parecen; son textos largos y feos, y a ojo rápido crm_test_a1b2 y crm_live_z9y8 se ven igual de ilegibles. Cómo detectarlo: antes de correr una prueba, lee la marca de la llave —test/live, sandbox/prod— y confirma la URL base. Si tu prueba deja un registro que aparece en el CRM de producción, usaste la llave equivocada. Cómo corregirlo: aprovecha que las llaves vienen marcadas; haz el hábito de verificar la marca como un piloto verifica el instrumento antes de despegar. Y estructura las credenciales por entorno (Módulo 4) para que la llave live viva solo en la instancia de prod, físicamente separada, de modo que ni siquiera esté disponible para copiarla por error en dev.

Meter la llave dentro del workflow en vez de en una credencial (práctico). Qué pasa: alguien pega la llave del CRM directamente en un campo del nodo HTTP —en la URL, en un header escrito a mano— en lugar de usar una credencial de n8n. Ahora la llave viaja dentro del JSON del workflow. Por qué pasa: es el atajo obvio; escribes la llave donde la necesitas. Cómo detectarlo: si al exportar order-triage con la CLI (Módulo 3) ves la llave en texto claro dentro del JSON, la metiste en el lugar equivocado. Cómo corregirlo: la llave va siempre en una credencial, y el workflow solo la referencia —es justo lo que aprendiste a separar en el Módulo 3, lección 3, y a manejar por entorno en el Módulo 4—. Una llave dentro del workflow rompe la separación por entorno (el JSON llevaría una llave fija en vez de resolverse por instancia) y, peor, se te sube a Git en claro.

Asumir que todo proveedor tiene sandbox (conceptual). Qué pasa: alguien planea su prueba dando por hecho que el CRM, la API o el servicio le va a dar una llave de prueba, y descubre a mitad de camino que no existe tal cosa (la modalidad C). Por qué pasa: los proveedores grandes y conocidos casi siempre tienen sandbox, y es fácil generalizar. Cómo detectarlo: antes de diseñar la prueba, busca en la doc del proveedor las palabras "sandbox", "test mode", "test key", "developer account". Si no aparecen, no hay modo de prueba nativo. Cómo corregirlo: no te bloquees. Cuando no hay sandbox, la protección la construyes tú —una cuenta de prueba armada a mano dentro del mismo sistema, más la compuerta de la lección 4 que corta el efecto antes de que ocurra—. Saber de antemano en qué modalidad estás (A, B o C) es parte de planear la prueba.

Ejercicios

Ejercicio 1 — Distingue las llaves. Para cada una de estas cinco credenciales, di si es de prueba o de producción y en qué te fijaste: (a) sk_test_51H8xY2...; (b) Authorization: Bearer crm_live_z9y8x7; (c) URL base https://sandbox-api.crm.example.com; (d) pk_live_4eC39Hq...; (e) una llave a1b2c3d4e5f6 sin ninguna marca ni URL.

Ver solución

(a) Prueba — el _test_ en el propio texto de la llave. (b) Producción — el _live_ en la llave. (c) Prueba — la palabra sandbox en la URL base; aunque no veas la llave, el destino es el cajón de arena. (d) Producción — el _live_; el prefijo pk_ indica que es una llave pública (publishable), pero eso es otra dimensión: pública/secreta es distinto de prueba/producción. (e) No se puede saber — no tiene marca ni URL. Y ese es el punto del ejercicio: una llave sin marca es peligrosa justamente porque no puedes distinguirla de un vistazo. Si te topas con una así, la única forma de saber es probar una acción reversible y ver dónde cae, o preguntarle al proveedor.

Por qué funciona: el hábito que entrena es leer la marca antes de correr, no después. Las dos dimensiones —prueba/producción y pública/secreta— son independientes, y confundirlas es un error común; por eso metí la (d).

Ejercicio 2 — Diseña la tabla de credenciales. order-triage va a agregar un nodo que manda un correo al cliente cuando su pedido queda en revisión manual, usando una API de correo (por ejemplo, un servicio como SendGrid o similar). Escribe la tabla de qué debe contener la credencial Email API en cada uno de los tres entornos —dev, staging, prod—, con qué llave y qué efecto tendría una llamada.

Ver solución

Instancia	Credencial Email API	Efecto de una llamada
dev	Llave de prueba del servicio de correo (o "sandbox mode" activado)	El correo se procesa pero no se entrega a nadie / va a una bandeja de captura de prueba. Reversible.
staging	Llave de prueba, o llave real apuntando solo a una dirección de prueba tuya	Ensayas la entrega real contra tu propio correo, nunca contra clientes.
prod	Llave de producción del servicio de correo	El correo le llega al cliente real. Definitivo, sin deshacer.

La clave: en dev nunca sale un correo al mundo. En staging puedes ensayar la entrega de verdad, pero contra una dirección tuya, no contra la lista de clientes. Solo en prod un envío alcanza a un cliente real. Y el workflow es el mismo en los tres: referencia Email API, y el entorno decide el destino.

Por qué funciona: mandar correos es la acción de la lista "nunca contra producción" que más rápido daña la reputación (le llega a una persona, no hay recall). Diseñar su credencial por entorno es aplicar la lección a un efecto secundario nuevo, que es exactamente lo que vas a hacer con el CRM en la lección 8.

Ejercicio 3 — Clasifica qué se prueba contra producción y qué no. Para cada acción, di si se puede probar directamente contra producción o no, y por qué: (a) leer la lista de clientes del CRM (solo lectura, sin escribir); (b) crear un cliente nuevo en el CRM; (c) consultar el clima en una API pública gratuita; (d) emitir una factura fiscal; (e) mandar un mensaje de Slack a un canal #test que creaste tú.

Ver solución

(a) Sí se puede (con cuidado) — es de solo lectura; leer no ensucia ni destruye nada. Aun así, gastar cuota de la API real por probar es un costo menor a considerar; si el proveedor tiene sandbox, úsalo igual. (b) No — crear un cliente escribe en producción; contamina los datos reales. Va contra el sandbox. (c) Sí se puede — es de solo lectura, contra un servicio gratuito, sin efectos. Aquí el sandbox es innecesario. (d) No, nunca — una factura fiscal es de las acciones más irreversibles que existen: tiene efectos legales y no se puede "desemitir". Solo con el modo de prueba del proveedor fiscal. (e) Sí, con matiz — el canal #test es tuyo y no le llega a un cliente, así que es un destino de prueba válido que armaste a mano (la modalidad C: te construiste tu propia separación). Mandar al canal #general de la empresa, en cambio, sí sería producción.

Por qué funciona: la pregunta de fuego —"¿puedo deshacerlo sin que nadie se entere?"— clasifica las cinco. Leer y consultar clima: sí, no hay efecto. Crear cliente, factura fiscal: no, hay efecto irreversible. El Slack depende de a quién le llega, y ahí ves que "producción" no es un servidor, es "donde caen efectos reales": un canal de prueba que tú controlas es sandbox aunque viva en el mismo Slack de la empresa.

Resumen y siguiente paso

En esta lección viste qué es una cuenta de prueba —la casa modelo de un servicio: idéntica a la real, pero de utilería— y una llave sandbox —la llave que abre la casa modelo, dinero de Monopoly en vez de dinero real—. Viste que los proveedores serios te dan dos llaves marcadas en su propio texto (test/live, sandbox/prod) justo para que no las confundas, con el test mode de una pasarela de pagos como ejemplo más estandarizado. Bajaste el patrón al CRM de Cumbre y sus tres modalidades posibles —cuenta sandbox separada, llave de prueba en la misma cuenta, o sin sandbox nativo—, y enganchaste la llave con las credenciales por entorno del Módulo 4: el mismo workflow order-triage, sin cambiar una línea, apunta al cajón de arena en dev/staging y al mundo en prod, porque es el entorno —no el workflow— el que decide el destino. Y grabaste la regla dura de qué no se prueba jamás contra producción: cobrar dinero, mandar mensajes a personas reales, escribir o borrar datos reales, disparar acciones irreversibles de terceros —todo lo que no tiene deshacer—.

Con esto marcas el primer punto del checklist: tu prueba corre contra llaves sandbox, no contra producción.

Antes de avanzar deberías poder: explicar en una frase la diferencia entre una llave de prueba y una de producción; describir por qué el mismo workflow puede apuntar a destinos distintos según el entorno; y recitar la pregunta de fuego que decide si algo se prueba contra producción o no.

Ya tienes el workflow conectado a un destino seguro. Lo que le falta son entradas seguras. La lección 3 entra en los datos sintéticos: por qué no se prueba con datos reales de clientes —privacidad e información personal—, cómo generar pedidos falsos pero realistas con el nodo Code o con datasets fijos, y —lo más valioso— cómo cubrir a propósito los casos borde y los datos sucios, para que tu prueba se parezca a la realidad y no a un caso feliz.

Recursos

• Credentials — n8n Docs — cómo n8n guarda y referencia credenciales; la base para separar la llave de prueba de la de producción por entorno.
• Manage credentials — n8n Docs — crear y editar una credencial en cada instancia, el paso concreto que hace esta lección.
• HTTP Request node — n8n Docs — el nodo de order-triage que le habla al CRM y donde se elige la credencial CRM API.
• Stripe test mode — Stripe Docs — el ejemplo canónico de un modo de prueba: llaves sk_test_, tarjetas de prueba y panel separado; verifica ahí los detalles exactos si usas Stripe.
• Environment variables in n8n — n8n Docs — cómo un entorno define su configuración, base del arreglo "una credencial por instancia" del Módulo 4.