Guía de integración de IBAN-Test
Validar IBAN en n8n con un flujo descargable
Importa un pequeño flujo manual, configura tus credenciales de la API de IBAN-Test y dirige los resultados a ramas VALID o INVALID. La plantilla comprueba un IBAN cada vez y se detiene si no puede obtener un resultado fiable.
Descarga el paquete inicial para n8n
El ZIP contiene el flujo en JSON, instrucciones de configuración, un script de comprobación sin conexión y su informe. Necesitas una instancia de n8n compatible con los nodos incluidos, permiso para crear credenciales y un token de la API de IBAN-Test con cuota disponible.
Descargar paquete inicial (ZIP)Estado de las pruebas: El informe incluido registra 24 comprobaciones superadas sin conexión con Node.js: casos de JavaScript, normalización, duplicados, límites, clasificación estricta de resultados, rechazo de respuestas contradictorias y configuración y conexiones del flujo. Las definiciones de los nodos se contrastaron con la documentación oficial y el código de n8n. No se disponía de una instalación de n8n ni de credenciales de API; siguen sin verificar la importación, la ejecución en n8n, la resolución de vínculos entre elementos y las llamadas autenticadas. Realiza la prueba manual descrita a continuación en tu propia instancia antes de depender del flujo.
Qué hace la plantilla
Úsala como primer paso antes de conectar un formulario, una hoja de cálculo o una base de datos interna. El flujo se inicia manualmente y contiene cuatro filas: un IBAN de ejemplo publicado, una versión con dígitos de control modificados, un duplicado y un valor vacío. Elimina espacios en blanco, convierte letras a mayúsculas, omite valores vacíos y agrupa duplicados. Conserva las posiciones originales en sourceRows, para asociar un resultado a varias filas.
El límite es de diez IBAN distintos y no vacíos por ejecución. Superarlo detiene el flujo antes de cualquier petición; no se descarta el resto silenciosamente. Se omiten los valores ausentes o vacíos, pero un valor que no sea una cadena detiene la preparación. Una entrada completamente vacía también detiene el proceso. Guarda los IBAN como texto en el origen.
Cada IBAN restante genera una petición REST independiente. Esta integración no utiliza un endpoint REST por lotes: diez IBAN distintos implican hasta diez llamadas. La eliminación de duplicados solo se aplica dentro de una ejecución; reiniciar vuelve a comprobar los valores. Consulta la documentación de la API de IBAN-Test al planificar el consumo.
1. Importa el archivo del flujo
Descomprime el ZIP y abre un flujo nuevo en n8n. En el menú de tres puntos de la esquina superior derecha, selecciona Import from File y el archivo iban-test-n8n-workflow.json. Guárdalo con un nombre reconocible. Estos pasos siguen la documentación de importación de n8n.
Deberías ver nueve nodos, empezando por Run manually. El nodo central One IBAN at a time utiliza lotes de un elemento. Su salida loop conduce a la petición HTTP y al clasificador, que vuelve al bucle. La salida done conduce a las ramas de resultados. No cambies estas conexiones durante la prueba.
2. Añade el token como credencial
Abre Validate IBAN. La autenticación usa Generic Credential Type con Header Auth. Crea o selecciona una credencial Header Auth con estos campos:
- Name:
Authorization - Value:
Bearer YOUR_API_TOKEN. Sustituye el marcador por tu token y conserva el espacio después deBearer.
Guarda y selecciona la credencial. El archivo no incluye identificadores de credenciales ni secretos. Mantén el token en el formulario de credenciales, no en el código ni en parámetros ordinarios de nodos. Consulta la referencia de credenciales HTTP Request de n8n.
La petición ya está configurada como POST https://www.iban-test.eu/api/v2/iban/validate. La expresión del cuerpo JSON es {{ { iban: $json.iban } }}. Solicita JSON e incluye el estado HTTP para que el siguiente nodo compruebe transporte y resultado de API. Los controles se explican en la documentación del nodo HTTP Request.
3. Ejecuta los ejemplos manualmente
Revisa los valores en Sample rows y ejecuta todo el flujo desde su disparador manual. Las filas suministradas se reducen a dos elementos de petición. Si la API responde correctamente, el ejemplo sin cambios debería llegar a VALID results y el de dígitos modificados a INVALID results. Son resultados esperados para tu primera prueba real, no una afirmación de que el paquete se haya probado con una cuenta autenticada.
Inspecciona iban, sourceRows, status y code en cada elemento de salida. Las ramas terminan en nodos No Operation para revisar resultados sin escribir en otros sistemas. Sustituye los ejemplos por unos pocos valores de prueba autorizados antes de conectar datos reales.
Cómo se separan resultados y fallos
| Respuesta | Acción del flujo |
|---|---|
HTTP 200, código 2100, error: false | Devolver VALID. |
HTTP 200, código 3100, 3101 o 3102, error: true | Devolver INVALID para su corrección. |
| Otro código, petición fallida o respuesta inesperada | Detener la ejecución para investigar. |
El clasificador exige un código numérico entero y un campo de error booleano. Los códigos de autenticación 4002, cuota 4003 y acceso deshabilitado 4004 detienen la ejecución. Un tiempo de espera agotado, un estado distinto de 200 o un cuerpo mal formado nunca se registra como IBAN inválido. Estas distinciones siguen los códigos de resultado documentados. Un IBAN válido no demuestra la titularidad ni garantiza un pago.
El nodo Loop Over Items espera la clasificación antes de pedir el siguiente elemento. Ante un fallo técnico, no se solicitan los IBAN posteriores ni se ejecutan las ramas finales. Las salidas previas pueden seguir visibles en el editor. Considera incompleta la ejecución.
Los reintentos automáticos están desactivados. Resuelve problemas de autenticación o cuota antes de reiniciar. Una repetición manual puede consumir llamadas adicionales para filas ya comprobadas. Si añades reintentos para fallos temporales, limita intentos y esperas; nunca reintentes en bucle entradas inválidas o una cuota agotada.
Antes de conectar datos de producción
La plantilla desactiva el guardado de datos de ejecuciones manuales, correctas y fallidas, así como del progreso. Verifica estos ajustes del flujo tras importar. Los IBAN y las respuestas pueden seguir apareciendo durante la ejecución; también importan las políticas de alojamiento, registros y copias de seguridad. No fijes datos reales de clientes ni compartas exportaciones que los incluyan.
Tras una prueba manual correcta, conecta cada rama a su destino. Conserva los identificadores de origen y evita registros duplicados al repetir ejecuciones. Añade una programación solo después de decidir zona horaria, presupuesto de cuota, avisos de error y comportamiento de reinicio.
También puedes empezar con la validación de IBAN en Google Sheets o la comprobación de un CSV con Python.
