Validación de datos en n8n: un ejercicio antes de escribir registros de empresas

Por Roman Rodomansky·Publicado el 20 oct 2026

Practica la validación de datos en n8n con registros sintéticos de empresas: detecta campos ausentes, vacíos e inválidos, conserva motivos y revisa ambas rutas.

• Transformación de datos
• Aprendizaje práctico
• Ejercicio

Comprobado con las fuentes citadas el 20 oct 2026.

Tu tarea de validación de datos en n8n y sus límites

Este ejercicio editorial te propone crear una validación de datos en n8n que envíe los registros de empresas aceptados hacia un punto de escritura y mantenga los rechazados disponibles para su corrección. Usa entradas sintéticas, conserva cada registro original y explica cada rechazo. El flujo propuesto y los resultados esperados no se han ejecutado ni validado.

Necesitas un entorno n8n con soporte para JavaScript en el nodo Code, conocimientos básicos de JavaScript y acceso a las salidas de los nodos. n8n documenta los pasos personalizados en JavaScript y el modo predeterminado Run Once for All Items; la documentación proporcionada no establece ninguna edición ni versión concreta. Comprueba la compatibilidad con Object.hasOwn() en tu entorno de ejecución si usas una instalación antigua.

Detente en un punto de inspección que represente el punto de escritura previsto. La configuración del destino y las operaciones reales de creación o actualización quedan fuera del alcance. Creemos que poder revisar los motivos de rechazo es tan importante como generar un payload aceptado.

Sources: n8n-docs/docs/reusable-content/.gitbook/includes/integrations/builtin/core-nodes/code-node.md at main · n8n-io/n8n-docs · GitHub, Object.hasOwn() - JavaScript | MDN

Define el contrato y las entradas sintéticas

Usa este contrato editorial: companyName y contactEmail deben existir, contener cadenas que no sean null y seguir teniendo contenido después de eliminar los espacios de los extremos. contactEmail también debe superar la comprobación de formato isEmail() documentada por n8n. Son reglas del ejercicio, no requisitos universales para los registros de empresas. La comprobación del correo no demuestra la existencia, la titularidad ni la capacidad de entrega del buzón; la fuente proporcionada no especifica la gramática que acepta.

Prepara los casos sugeridos a continuación para la validación de datos en n8n. Cada registro tiene el caseId indicado; los campos no especificados usan companyName = Acme y contactEmail = hello@example.com. Las comillas indican valores de cadena, mientras que null, los números y los booleanos indican sus tipos correspondientes. Las decisiones y los motivos son expectativas propuestas.

Sources: n8n-docs/docs/build/work-with-data/transform-data/expression-reference/string.md at main · n8n-io/n8n-docs · GitHub

Solución sugerida: inspecciona los campos y conserva los motivos

En los nodos de n8n, la validación de datos de este ejercicio separa la inspección de campos del enrutamiento. Empieza con un nodo Code de JavaScript en modo Run Once for All Items. Lee $input.all() y procesa cada elemento, cuyos datos habituales se encuentran bajo json. Devuelve por cada entrada un resultado envuelto en json que contenga caseId, original, normalized, validationErrors e isValid; mantén los metadatos de validación fuera del registro original.

Sigue este algoritmo sugerido para cada campo obligatorio. Object.hasOwn() distingue una propiedad ausente de una presente, incluso si contiene null o undefined. Comprueba null por separado porque typeof de JavaScript lo identifica como un objeto. Comprueba el tipo string antes de usar trim(), que devuelve una cadena nueva sin modificar la original.

1. Si el campo no es una propiedad propia del objeto, añade su motivo missing y deja de comprobar ese campo.
2. Si su valor es null o undefined, añade empty y deja de comprobar ese campo.
3. Si su tipo no es string, añade invalid_type y deja de comprobar ese campo.
4. Guarda en normalized la cadena tras aplicar trim(); si queda vacía, añade empty.
5. Continúa con el otro campo obligatorio para que los fallos simultáneos sigan siendo visibles.

Trata el formato del correo como una comprobación independiente mediante una expresión de n8n que use normalized.contactEmail.isEmail(), a la que solo se llegue si la cadena no está vacía. Lleva su resultado a un paso final de JavaScript que añada contactEmail: invalid_email cuando sea false y después establezca isValid a partir de validationErrors.length === 0. Así evitas asumir que las funciones auxiliares de las expresiones de n8n son métodos ordinarios de JavaScript.

La guía Production AI Playbook de n8n de 2026 ilustra el uso de validationErrors y un indicador isValid para las salidas de IA; este ejercicio adapta ese patrón a los registros de empresas. En nuestra opinión, aquí resulta más útil un motivo preciso por cada campo que falle que encadenar varios errores derivados del mismo valor ausente.

Sources: n8n-docs/docs/reusable-content/.gitbook/includes/integrations/builtin/core-nodes/code-node.md at main · n8n-io/n8n-docs · GitHub, n8n-docs/docs/build/work-with-data/transform-data/expression-reference/README.md at main · n8n-io/n8n-docs · GitHub, n8n-docs/docs/build/work-with-data/understand-n8ns-data-structure.md at main · n8n-io/n8n-docs · GitHub, Object.hasOwn() - JavaScript | MDN, typeof - JavaScript | MDN, String.prototype.trim() - JavaScript | MDN, n8n-docs/docs/build/work-with-data/transform-data/expression-reference/string.md at main · n8n-io/n8n-docs · GitHub, Production AI Playbook: Deterministic Steps & AI Steps – n8n Blog

Enruta los registros y comprueba la finalización

Usa un nodo If para comparar isValid con el booleano true. n8n documenta la bifurcación condicional mediante operaciones de comparación. Conecta la rama true al punto de inspección y la rama false a revisión; no vuelvas a conectar la revisión con la ruta de escritura. La siguiente lista define los criterios de finalización propuestos para tu ejercicio de validación de datos en n8n.

• Cada caseId aparece exactamente una vez entre las dos ramas con la decisión esperada.
• Los registros rechazados conservan sus originales y todos los motivos de campo esperados.
• Los registros aceptados no tienen errores de validación; C10 tiene companyName = Acme en normalized.
• Ningún caseId rechazado llega al punto de escritura.

Inspecciona las salidas de ambas ramas y el historial de ejecuciones. El artículo de n8n sobre API Contract Testing de 2026 recomienda conservar el historial de ejecuciones como evidencia de validación. Esta prueba sin escrituras demuestra únicamente el enrutamiento; establecer que un destino externo no recibió escrituras requiere una comprobación aparte con un destino de pruebas aislado.

Si las decisiones no son las esperadas, inspecciona la escritura de los nombres de campo, el tratamiento de null, las comprobaciones de tipo anteriores a trim(), las comparaciones de booleanos frente a cadenas, la conservación de caseId y las conexiones entre ramas. Reflexión sugerida: ¿por qué un null presente difiere de una clave ausente y qué evidencia justificaría cambiar una regla de rechazo?

Sources: Object.hasOwn() - JavaScript | MDN, typeof - JavaScript | MDN, String.prototype.trim() - JavaScript | MDN, n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.if.md at main · n8n-io/n8n-docs · GitHub, API Contract Testing: Prevent Downstream Failures — n8n Blog – n8n Blog