Documentation API Technique SEPA : Guide Complet 2026
2026-06-14
Vous ne partez généralement pas d’une page blanche. Vous disposez déjà de données de paiement dans un ERP, un outil de comptabilité, un export CSV ou un flux de travail AEB hérité. Le problème commence lorsque ces données doivent devenir un XML SEPA valide sans nettoyage manuel, sans rejets bancaires répétés ni équipe finance se demandant pourquoi un champ apparemment optionnel s’avère obligatoire.
C’est là que la documentation API technique échoue souvent. Elle indique à un développeur quel point de terminaison accepte une charge utile, mais n’explique pas pourquoi une référence de mandat manquante pose problème, pourquoi le type de séquence change la signification d’un prélèvement, ou pourquoi un IBAN plausible peut quand même déclencher des frais de rejet en aval. Dans les flux de paiement, la syntaxe n’est que la moitié du travail.
Une bonne documentation API technique doit relier le corps de la requête à l’événement métier. C’est important car des docs claires et interactives peuvent réduire le temps d’intégration de jusqu’à 50 % et le volume de tickets de support de 30 à 40 %.
Introduction et démarrage
La génération manuelle de fichiers SEPA échoue toujours aux mêmes endroits. Un export a le mauvais format de date. Un compte créancier est valide en interne mais pas pour la banque. Un utilisateur finance saisit le concept de paiement tel qu’il apparaît sur une facture, mais le fichier bancaire attend une structure plus stricte.
L’approche API est plus simple. Votre système envoie du JSON, le service valide les données et la sortie est un fichier XML SEPA prêt pour la banque. Cela supprime l’étape où quelqu’un doit manuellement transformer des données opérationnelles en une structure XML que la plupart des utilisateurs professionnels ne devraient jamais avoir à toucher.
À quoi sert l’API
Concrètement, l’API gère trois tâches :
- Réception des données : votre application soumet des données de remise en JSON.
- Transformation orientée conformité : le service transforme ces données dans la structure SEPA correcte.
- Livraison du fichier : votre système reçoit l’accès au XML généré pour le transmettre au flux bancaire.
Votre première étape obligatoire
L’authentification vient en premier. L’accès est contrôlé avec une clé API que vous obtenez depuis votre tableau de bord de compte.
Règle pratique : Traitez la clé API comme une information d’identification de production dès le premier jour, même pendant les tests. La plupart des problèmes d’intégration commencent parce que les équipes traitent la première clé de test comme une donnée jetable puis copient les mêmes habitudes en production.
URL de base et état d’esprit du premier appel
Utilisez une seule URL de base pour toutes les requêtes :
https://api.[generatesepa](/fr).com
Votre premier appel réussi doit viser un résultat précis : soumettre une remise minimale mais valide et confirmer que vous recevez une réponse de création plus un chemin de récupération de fichier.
Concepts clés et flux de travail de l’API
Les équipes pensent souvent qu’elles intègrent un générateur de fichiers. Ce n’est pas le cas. Elles intègrent un flux de paiement avec des hypothèses réglementaires et bancaires intégrées.

L’objet remise
L’objet central est la remise. Pensez-y comme au conteneur métier d’un lot de transactions qui appartiennent ensemble. Une remise contient généralement :
- Données du créancier ou de l’émetteur : l’entité juridique initiant le virement ou le prélèvement.
- Contexte d’exécution : quand la banque doit traiter la remise.
- Lignes de transaction : les débiteurs ou bénéficiaires individuels.
- Identifiants de schéma : champs qui relient la requête aux exigences spécifiques SEPA.
Pourquoi les champs SEPA existent
Plusieurs champs créent de la confusion parce qu’ils semblent administratifs plutôt que techniques. En pratique, ils ne sont pas optionnels.
- ID créancier : identifie la partie qui collecte les prélèvements.
- ID mandat : relie un débit à l’autorisation signée du débiteur.
- Type de séquence : les valeurs comme FRST et RCUR indiquent à la banque si un débit est le premier d’une série de mandat ou une collecte récurrente.
Le flux de travail en pratique
Le flux réel est simple une fois que vous séparez les étapes :
- Votre système envoie du JSON avec les métadonnées de remise et les lignes de transaction.
- L’API valide les champs critiques comme les identifiants, les formats de date et les données de compte.
- Le service convertit la requête en XML SEPA en utilisant la structure appropriée.
- Votre système reçoit un résultat confirmant le traitement et fournissant l’accès au fichier généré.
- Le processus finance continue avec le téléchargement et la soumission à la banque.
Authentification et protocoles de sécurité
L’authentification API utilise le schéma Bearer dans l’en-tête Authorization.
Format d’en-tête
Utilisez ce modèle exact :
Authorization: Bearer VOTRE_CLE_API
Un exemple HTTP minimal (générique, avec un hôte fictif) ressemble à ceci :
POST /v1/remittances HTTP/1.1
Host: api.example.com
Authorization: Bearer VOTRE_CLE_API
Content-Type: application/json
Comment stocker la clé
Intégrer la clé dans les fichiers source est le moyen le plus rapide de créer un problème ultérieur. Stockez-la dans une variable d’environnement et lisez-la au moment de l’exécution.
Gestion recommandée :
- Développement local : conservez la clé dans un fichier d’environnement local non versionné.
- Environnements partagés : injectez la clé via le gestionnaire de secrets de votre plateforme de déploiement.
- Rotations : concevez votre application pour que la clé puisse être remplacée sans modifications de code.
- Journalisation : ne jamais afficher la clé complète dans les journaux d’application.
Modèle de sécurité autour de la requête
Toutes les données en transit sont chiffrées avec TLS 1.2+. Les données de remise client sont automatiquement supprimées des serveurs 10 minutes après le traitement.
Référence des points de terminaison — Création de remise
Le point de terminaison principal pour la génération de fichiers est :
POST /v1/remittances

Exemple de corps de requête
{
"type": "direct_debit",
"execution_date": "2026-06-30",
"creditor_name": "Acme Services S.L.",
"creditor_iban": "ES9121000418450200051332",
"creditor_id": "ES98ZZZ123456789",
"currency": "EUR",
"sequence_type": "FRST",
"transactions": [
{
"debtor_name": "Laura Martin",
"debtor_iban": "ES7921000813610123456789",
"amount": 125.50,
"concept": "Facture INV-2026-0042",
"mandate_id": "MANDATE-00045",
"mandate_signature_date": "2025-12-15",
"end_to_end_id": "INV-2026-0042"
}
]
}
Référence des champs
| Champ | Type | Requis | Description |
|---|---|---|---|
type |
chaîne | Oui | Type de remise : prélèvement ou virement |
execution_date |
chaîne | Oui | Date de traitement au format ISO 8601 |
creditor_name |
chaîne | Oui | Nom légal ou opérationnel de la partie initiatrice |
creditor_iban |
chaîne | Oui | IBAN du compte qui envoie ou collecte les fonds |
creditor_id |
chaîne | Requis pour prélèvement | Identifiant créancier SEPA |
currency |
chaîne | Oui | Code de devise. Utiliser EUR pour les remises SEPA |
sequence_type |
chaîne | Requis pour prélèvement | Séquence de débit comme FRST ou RCUR
|
transactions |
tableau | Oui | Liste d’instructions de paiement ou de débit |
Règles de validation importantes
-
Les dates doivent utiliser ISO 8601. Utilisez
YYYY-MM-DD. N’envoyez pas de dates spécifiques aux paramètres régionaux. - Les valeurs IBAN sont validées pour la structure du code pays, la longueur attendue et la logique de somme de contrôle.
- Le texte du concept doit rester concis. Ne le traitez pas comme un champ de note libre.
-
Le type de séquence doit correspondre à l’état du mandat.
FRSTetRCURne sont pas des étiquettes interchangeables.
Comprendre les réponses de l’API
Une requête de création réussie renvoie 201 Created et un corps JSON.
Exemple de réponse de succès
{
"remittance_id": "rem_8f3c2a91",
"status": "completed",
"download_url": "https://api.example.com/downloads/rem_8f3c2a91.xml",
"expires_at": "2026-06-25T10:25:00Z"
}
Ce que fait un client mature après le succès
- Stocker
remittance_idavec l’ID de lot interne d’origine. - Vérifier que
statusindique la complétion. - Télécharger le XML depuis
download_url. - Sauvegarder le fichier dans votre propre stockage ou le transmettre au processus interne suivant.
- Enregistrer le résultat de récupération pour l’auditabilité.
Gestion des erreurs et codes de référence
| Statut HTTP | Code d’erreur | Description | Action suggérée |
|---|---|---|---|
400 |
INVALID_REQUEST |
Corps de requête malformé ou champs requis manquants | Valider la structure JSON avant de resoumettre |
400 |
INVALID_IBAN |
Un des champs IBAN a échoué à la validation | Vérifier le code pays, la longueur et la saisie de somme de contrôle |
400 |
INVALID_DATE_FORMAT |
Un champ de date n’utilise pas le format attendu | Envoyer les dates au format ISO 8601 |
401 |
UNAUTHORIZED |
Clé API manquante, expirée ou invalide | Vérifier l’en-tête Authorization: Bearer
|
429 |
RATE_LIMITED |
Trop de requêtes envoyées en peu de temps | Ralentir le débit et réessayer selon votre politique de back-off |
500 |
INTERNAL_ERROR |
Le service a échoué lors du traitement | Réessayer si approprié et journaliser le contexte |
La documentation est l’un des points à vérifier avant de choisir un outil : voyez nos critères de sélection d’un fournisseur SEPA et notre guide sur l’API de prélèvement SEPA.
Exemples d’intégration pratiques

Exemple cURL
curl -X POST "https://api.example.com/v1/remittances" \
-H "Authorization: Bearer $GENERATESEPA_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"type": "direct_debit",
"execution_date": "2026-06-30",
"creditor_name": "Acme Services S.L.",
"creditor_iban": "ES9121000418450200051332",
"creditor_id": "ES98ZZZ123456789",
"currency": "EUR",
"sequence_type": "FRST",
"transactions": [
{
"debtor_name": "Laura Martin",
"debtor_iban": "ES7921000813610123456789",
"amount": 125.50,
"concept": "Facture INV-2026-0042",
"mandate_id": "MANDATE-00045",
"mandate_signature_date": "2025-12-15",
"end_to_end_id": "INV-2026-0042"
}
]
}'
Exemple Python
import os
import requests
api_key = os.environ.get("GENERATESEPA_API_KEY")
payload = {
"type": "direct_debit",
"execution_date": "2026-06-30",
"creditor_name": "Acme Services S.L.",
"creditor_iban": "ES9121000418450200051332",
"creditor_id": "ES98ZZZ123456789",
"currency": "EUR",
"sequence_type": "FRST",
"transactions": [
{
"debtor_name": "Laura Martin",
"debtor_iban": "ES7921000813610123456789",
"amount": 125.50,
"concept": "Facture INV-2026-0042",
"mandate_id": "MANDATE-00045",
"mandate_signature_date": "2025-12-15",
"end_to_end_id": "INV-2026-0042"
}
]
}
headers = {
"Authorization": f"Bearer {api_key}",
"Content-Type": "application/json"
}
response = requests.post(
"https://api.example.com/v1/remittances",
json=payload,
headers=headers,
timeout=30
)
if response.status_code == 201:
data = response.json()
print("Remise créée :", data["remittance_id"])
print("Statut :", data["status"])
print("URL de téléchargement :", data["download_url"])
else:
error = response.json()
print("Statut HTTP :", response.status_code)
print("Code d'erreur :", error.get("error_code"))
print("Message :", error.get("error_message"))
Si vous souhaitez arrêter de construire manuellement des fichiers SEPA et passer à un flux de travail JSON vers XML validé, GenerateSEPA offre aux équipes techniques et aux services financiers un moyen pratique d’automatiser les remises et de produire des XML SEPA prêts pour la banque.
Questions fréquentes
- Qu'est-ce qu'une documentation API technique pour SEPA ?
- Une documentation API technique SEPA explique comment envoyer des données de paiement en JSON à un service qui les transforme en fichiers XML SEPA valides. Elle couvre l'authentification, les champs requis, les règles de validation spécifiques à SEPA (comme les types de séquence et les IDs mandat), les exemples de code et la gestion des erreurs.
- Pourquoi le type de séquence FRST vs RCUR est-il important dans l'API SEPA ?
- FRST indique le premier prélèvement d'une série de mandat, tandis que RCUR indique un prélèvement récurrent. Choisir le mauvais type n'est pas une erreur de formatage : cela change la signification légale et bancaire de l'instruction de paiement. Les banques traitent différemment les premiers prélèvements par rapport aux récurrents.
- Comment sécuriser une clé API d'intégration SEPA ?
- Stockez la clé dans une variable d'environnement, ne la codez jamais en dur dans le code source, injectez-la via un gestionnaire de secrets en production, et ne l'affichez jamais dans les journaux d'application. Utilisez une clé différente par environnement (développement, test, production).
- Que faire si l'API renvoie une erreur INVALID_IBAN ?
- Vérifiez le code pays de l'IBAN, sa longueur attendue pour ce pays et la logique de somme de contrôle. Un IBAN qui semble correct à l'utilisateur peut quand même échouer à la validation SEPA. Utilisez un outil de validation IBAN avant la soumission pour éviter des frais de rejet bancaire.