Tabla de consulta en n8n: un ejercicio para validar payloads de API

Por Roman Rodomansky·Publicado el 22 oct 2026

Crea una tabla de consulta en n8n que conserve duplicados, compruebe códigos y caducidad, y derive los payloads de API propuestos a revisión.

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

Comprobado con las fuentes citadas el 22 oct 2026.

Tu ejercicio de tabla de consulta en n8n

Crea una tabla de consulta en n8n que prepare un payload solo cuando una etiqueta entrante tenga exactamente una fila de referencia, un código aprobado y una correspondencia sin caducar. Este es un ejercicio editorial basado en capacidades documentadas: sus datos de prueba, algoritmo y resultados esperados son propuestas, sin ejecución ni validación aportadas.

Usa datos sintéticos en tu propio entorno de n8n. Necesitas Data Tables, permiso para crear una tabla y familiaridad con los nodos Code de JavaScript y las bifurcaciones IF. n8n documenta Data Tables para consultas desde workflows e importación de CSV, pero la documentación proporcionada no establece una versión ni un plan mínimos; comprueba que tu entorno incluya esta función. Las tablas pertenecen a un proyecto y están pensadas para un almacenamiento ligero o moderado.

Termina con salidas separadas para los payloads aptos y los registros que requieren revisión. La configuración HTTP, la autenticación, las escrituras reales y la aplicación de restricciones en el destino quedan fuera del alcance. Para completar el ejercicio, cada identificador de entrada debe aparecer exactamente una vez, con el resultado esperado que se indica más adelante.

Sources: n8n-docs/docs/build/work-with-data/data-tables.md at main · n8n-io/n8n-docs · GitHub

Prepara las filas de referencia y los registros entrantes

Crea un CSV con las cabeceras label, apiCode y expiresAt usando exactamente los datos de prueba editoriales que aparecen a continuación e impórtalo en una Data Table llamada reference_codes. El campo apiCode de Blank está vacío; Unknown no tiene ninguna fila de referencia. Usa EXP, ECO, EC2, LEG y BRK como conjunto de códigos aprobados del ejercicio; estos códigos ficticios no establecen nada sobre una API externa. Fija el momento de evaluación en 2026-10-22T00:00:00Z.

label,apiCode,expiresAt Express,EXP,2027-01-01T00:00:00Z Economy,ECO,2027-01-01T00:00:00Z Economy,EC2,2027-01-01T00:00:00Z Legacy,LEG,2026-01-01T00:00:00Z Broken,BRK,not-a-date Blank,,2027-01-01T00:00:00Z Boundary,EXP,2026-10-22T00:00:00Z

Usa los siguientes registros entrantes para tu ejercicio de tabla de consulta en n8n. Las etiquetas deben coincidir exactamente, incluidas las mayúsculas, las minúsculas y los espacios en blanco.

Recupera la tabla con Data Table Get y Return All activado. No la modifiques durante la recuperación: n8n documenta posibles incoherencias cuando se realizan cambios durante una recuperación paginada. En este diseño, pasa la salida recuperada del workflow a Code.

Sources: n8n-docs/docs/build/work-with-data/data-tables.md at main · n8n-io/n8n-docs · GitHub, n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.datatable/rows.md at main · n8n-io/n8n-docs · GitHub

Solución sugerida: conserva la ambigüedad antes de comprobar la caducidad

Usa esta secuencia sugerida: Incoming records → Get reference rows → Build index → Evaluate. Haz que Incoming records sea un nodo Code que devuelva un elemento cuyo json contenga un array records con los siete objetos de identificador y etiqueta. Get reference rows recupera todas las filas con una etiqueta no vacía y Return All activado. La guía de Code de n8n permite combinar datos de referencia con otro conjunto de datos y devolver elementos del workflow como un array de objetos { json: ... }.

Ejecuta Build index una vez para todos los elementos. Agrupa las filas de $input.all() por etiqueta exacta en un Map de JavaScript llamado index, conservando arrays de filas de referencia completas, y devuelve [{ json: { byLabel: Object.fromEntries(index) } }]. El array de Economy debe contener ambas filas. Ejecuta Evaluate una vez para todos los elementos: lee el índice desde $input.first().json.byLabel y los registros originales desde $('Incoming records').first().json.records. Para cada registro, recupera los candidatos con byLabel[record.label] ?? []. Recorre ese array records, en lugar de las filas de referencia, para que Unknown también reciba un resultado. Estos ejemplos resueltos muestran los elementos propuestos del workflow.

Para las fechas, n8n documenta que los valores pasan entre nodos como cadenas y requieren análisis. En JavaScript, usa DateTime.fromISO de Luxon con una zona UTC explícita, comprueba isValid y compara los valores de toMillis(). La documentación de Luxon 3.7.2 incluye la comprobación de validez y la conversión de marcas de tiempo; no establece la versión incluida en tu instalación. Las marcas de tiempo UTC explícitas evitan depender de la interpretación de la zona horaria del workflow.

Creemos que la ambigüedad merece su propio motivo de rechazo: seleccionar una fila conveniente oculta la decisión que quien aprende necesita examinar. Sigue este orden de validación propuesto.

1. Agrupa las filas de referencia por etiqueta exacta en arrays, conservando todos los duplicados. Un Map de JavaScript puede almacenar cada etiqueta y su array.
2. Para cada registro entrante, recupera sus coincidencias. Emite missing si no hay coincidencias y ambiguous si hay más de una; deja de evaluar ese registro.
3. Para la única coincidencia, exige un apiCode de tipo cadena cuyo valor sin espacios al principio y al final no esté vacío y cuyo valor original pertenezca al conjunto declarado de códigos aprobados. En caso contrario, emite invalid_code.
4. Analiza expiresAt. Emite invalid_expiry si el análisis no es válido; en caso contrario, emite expired cuando su marca de tiempo sea menor o igual que la marca de tiempo de evaluación.
5. Emite un elemento { json: result } por entrada. Conserva su identifier y label, eligibility y reason. Añade payload con identifier y el apiCode correspondiente solo cuando sea apto; en caso contrario, omite payload y apiCode.

Sources: skills/skills/n8n-code-nodes-official/SKILL.md at main · n8n-io/skills · GitHub, n8n-docs/docs/build/work-with-data/handle-special-data-types/work-with-dates-and-times.md at main · n8n-io/n8n-docs · GitHub, luxon 3.7.2 | Documentation

Dirige los resultados y comprueba que el ejercicio esté completo

Configura IF para enviar los elementos con eligibility igual a true a la salida de payloads y todos los demás a revisión. La guía de implementación comercial de Suyash Raj de 2026 describe las bifurcaciones IF para registros válidos e inválidos. Configura los errores de los nodos como Stop Workflow, que, según documenta n8n, detiene la ejecución. Los rechazos por reglas de negocio siguen requiriendo las reglas explícitas anteriores.

Usa Execute step para inspeccionar por separado las salidas de consulta y validación. Compara los resultados con estas comprobaciones de aceptación del ejercicio editorial.

• Solo Express llega a la salida de registros aptos con payload.apiCode igual a EXP.
• Economy, Legacy, Broken y Unknown llegan a revisión con ambiguous, expired, invalid_expiry y missing, respectivamente.
• Blank y Boundary llegan a revisión con invalid_code y expired, respectivamente.
• Los siete identificadores aparecen exactamente una vez entre ambas salidas; los elementos rechazados no contienen payload ni apiCode.
• La salida de referencia recuperada conserva ambas filas de Economy y ninguna ruta elude la validación.

Sources: n8n-docs/docs/build/understand-workflows/workflow-components/work-with-nodes.md at main · n8n-io/n8n-docs · GitHub, n8n Data Validation & Cleaning Workflows | Suyash Raj

Reflexiona sobre la decisión de correspondencia

Si los resultados difieren, inspecciona la cantidad de filas recuperadas, la agrupación de duplicados, la escritura exacta de las etiquetas y los valores de caducidad analizados. No introduzcas normalización salvo que apliques explícitamente la misma regla a ambos conjuntos de datos.

Explica qué ocurriría si una fila de Economy caducara, pero la otra siguiera vigente. Según las reglas de este ejercicio, primero se cuentan los duplicados, por lo que la correspondencia sigue siendo ambigua. Después, explica por qué elegir la primera coincidencia o proporcionar un código predeterminado incumpliría el contrato.

En nuestra opinión, una tabla de consulta en n8n debería mostrar las decisiones pendientes antes de dejar pasar un payload. Este ejercicio no establece atomicidad con una escritura posterior en la API ni protege frente a cambios en los datos de referencia después de la consulta.