Guide d’intégration IBAN-Test

Valider des IBAN dans n8n avec un workflow à télécharger

Importez un petit workflow manuel, configurez vos identifiants API IBAN-Test et dirigez les résultats vers les branches VALID ou INVALID. Le modèle vérifie un IBAN à la fois et s’arrête s’il ne peut pas obtenir de résultat fiable.

État des tests : Le rapport inclus documente 24 tests hors ligne réussis avec Node.js : cas de test JavaScript, normalisation, doublons, limites, classification stricte des résultats, rejet des réponses contradictoires et configuration et connexions du flux de travail. Les définitions de nœuds ont été vérifiées par rapport à la documentation officielle n8n et au code source. Un runtime n8n installé et les informations d'identification de l'API n'étaient pas disponibles. L'import, l'exécution dans n8n, le mappage des éléments liés et les appels API authentifiés ne sont donc pas encore testés. Avant de vous appuyer sur le workflow, effectuez le test manuel décrit ci-dessous dans votre instance.

Ce que fait le modèle

Utilisez-les comme point de départ avant de connecter un formulaire client, une table ou une base de données interne. Le workflow démarre manuellement et contient quatre lignes d'exemple : un exemple d'IBAN publié, une variante avec un chiffre de contrôle modifié, un doublon et une valeur vide. Il supprime les espaces blancs, convertit les lettres en majuscules, ignore les valeurs vides et regroupe les doublons. Les positions de ligne d'origine sont conservées dans sourceRows, afin qu'un résultat puisse être affecté à plusieurs lignes.

Dix IBAN différents et non vides sont autorisés par exécution. S'il y en a plus de dix, le workflow s'arrête avant la première requête ; les valeurs excédentaires ne sont pas ignorées en silence. Les valeurs manquantes ou vides sont ignorées, mais les valeurs sans type de chaîne arrêtent la préparation. Même une entrée complètement vide entraîne un arrêt. Enregistrez les IBAN dans votre source sous forme de texte.

Une demande REST distincte est effectuée pour chaque IBAN restant. Cette intégration n'utilise pas de point de terminaison REST pour les requêtes groupées : dix IBAN différents signifient jusqu'à dix appels de validation. Le nettoyage des doublons s’applique en une seule exécution. Un redémarrage vérifie à nouveau les mêmes valeurs. Consultez la documentation de l’API IBAN-Test lors de la planification.

1. Importer le fichier de flux de travail

Décompressez le fichier ZIP et ouvrez un nouveau workflow dans n8n. Dans le menu à trois points en haut à droite, sélectionnez Import from File puis iban-test-n8n-workflow.json. Enregistrez le flux de travail sous un nom significatif. Ces étapes correspondent à instructions d'importation du flux de travail n8n.

Vous devez voir neuf nœuds, à commencer par Run manually. Le nœud central One IBAN at a time utilise des lots d’un élément. Sa sortie loop mène à la requête HTTP et au classificateur, qui revient dans la boucle. Sa sortie done mène aux branches de résultats. Ne modifiez pas ces connexions pendant le test.

2. Stocker le jeton API en tant que données d'accès

Ouvrez Validate IBAN. L'authentification est configurée comme Generic Credential Type avec Header Auth. Créez des informations d'identification d'authentification d'en-tête avec les champs suivants ou sélectionnez celles existantes :

• Name: Authorization
• Value: Bearer YOUR_API_TOKEN. Remplacez l'espace réservé par votre jeton et conservez l'espace après Bearer.

Enregistrez et sélectionnez ces informations d'identification. Le téléchargement ne contient intentionnellement ni identifiant de données d'accès ni secret. Stockez votre jeton uniquement sous la forme d'informations d'identification, pas dans l'exemple de code ou dans les paramètres de nœud ordinaires. Voir le référence n8n aux informations d'identification de la requête HTTP.

La demande est déjà configurée comme POST https://www.iban-test.eu/api/v2/iban/validate. L'expression du corps JSON est {{ { iban: $json.iban } }}. Une réponse JSON incluant l'état HTTP est demandée afin que le nœud suivant puisse vérifier à la fois la transmission et le résultat de l'API. Les paramètres sont décrits dans le Documentation du nœud de requête HTTP.

3. Exécutez les exemples manuellement

Ouvrez Sample rows et vérifiez les exemples de valeurs. Démarrez ensuite l’ensemble du workflow via son déclencheur manuel. Deux éléments de requête sont créés à partir des lignes données. Si l'API est exécutée avec succès, l'exemple inchangé doit apparaître sous VALID results, la variante avec un chiffre de contrôle modifié sous INVALID results. Il s'agit des résultats attendus de votre premier test en direct, et non d'une affirmation selon laquelle le téléchargement a déjà été testé avec un compte authentifié.

Pour chaque élément de sortie, cochez iban, sourceRows, status et code. Les branches se terminent actuellement par des nœuds sans opération où vous pouvez afficher les résultats sans écrire sur un autre système. Remplacez les exemples par quelques valeurs de test publiées avant de connecter une véritable source de données.

Distinguer les résultats des tests et les erreurs techniques

La classification nécessite un code numérique entier et un champ d'erreur booléen. Le code d'authentification 4002, le code de quota 4003 et le code d'accès bloqué 4004 arrêtent le flux. Un délai d'attente, un statut HTTP autre que 200 ou un contenu de réponse incorrect ne sont jamais enregistrés comme un IBAN invalide. La base est le codes de résultat API documentés. Un IBAN valide ne prouve ni la propriété du compte ni ne garantit le paiement.

Le Boucle de nœud sur les éléments attend la classification avant de demander l'élément suivant. En cas d'erreur technique, les IBAN ultérieurs ne seront plus demandés et les branchements du résultat final ne seront pas exécutés. La sortie du nœud précédent peut toujours être visible dans l'éditeur. Considérez l'exécution comme incomplète.

Les répétitions automatiques sont désactivées. Résolvez les problèmes d’authentification ou de quota avant de redémarrer. Un redémarrage manuel peut consommer des appels supplémentaires pour les lignes déjà vérifiées. Si vous ajoutez des tentatives ultérieurement pour des erreurs temporaires, limitez le nombre et les temps d'attente. Ne répétez jamais une entrée ou une demande invalide en boucle lorsque le quota est épuisé.

Avant de connecter des données productives

Le modèle désactive l’enregistrement des données et de la progression de la réussite et de l’échec de l’exécution manuelle. Vérifiez ce Paramètres du flux de travail après l'importation. Les IBAN et les réponses API peuvent toujours être visibles pendant l'exécution ; Les règles d'hébergement, de journalisation et de sauvegarde jouent également un rôle. N'épinglez pas de données client réelles sur des nœuds et ne partagez pas d'exportations de flux de travail contenant de telles données.

Après un test manuel réussi, connectez chaque branche de résultat à sa cible prévue. Préservez les identifiants de source et évitez les enregistrements en double lors des exécutions répétées. Ajoutez une planification uniquement une fois que le fuseau horaire, le budget de quota, les messages d'erreur et le comportement de redémarrage ont été déterminés.

Les instructions du Vérification IBAN dans Google Sheets et du Vérifier un IBAN CSV avec Python fournissent des informations supplémentaires.