API
Intégrateur Qonto API : rapprocher banque, pièces et comptabilité
Dawap relie les comptes et transactions Qonto à votre ERP, logiciel comptable, gestion des dépenses ou cockpit finance. Le connecteur ne transforme pas chaque mouvement bancaire en écriture par réflexe : il conserve l’identité Qonto, suit les changements de statut, contrôle la pièce, applique le mapping validé et explique pourquoi la clôture peut accepter, isoler ou reprendre l’opération.
- Chronologie bancaire conservée
- Pièce et owner explicites
- Balance de clôture vérifiée
APIs, données et infrastructures que nos projets savent connecter
Conception, intégration et maintenance
01
Contrat
versionné
02
Sécurité
explicite
03
Reprise
testée
04
Supervision
avec alertes
Réponse immédiate
Un intégrateur Qonto API relie chaque mouvement bancaire à la pièce, l’owner et l’écriture qui expliquent la clôture.
Dawap utilise la Qonto Business API pour lire comptes et transactions, suivre leurs statuts, récupérer ou déposer les justificatifs autorisés et alimenter l’ERP, la comptabilité ou la BI. Le middleware conserve transaction ID, compte, montant, devise et dates, applique un mapping versionné, contrôle les webhooks signés et réconcilie la balance avant de confirmer une écriture.
- Lire les comptes puis les transactions par bank_account_id ou IBAN et fenêtre updated_at.
- Séparer mouvement pending, declined ou completed avant toute projection comptable.
- Rattacher facture, justificatif, fournisseur, TVA et owner sans inventer une correspondance.
- Journaliser balance, écart, décision et reprise avec des droits OAuth minimaux.
Dossier de clôture · scénario illustratif
Un mouvement bancaire n’est prêt que lorsque la finance peut reconstruire sa décision.
Le dossier fictif ci-dessous suit la même transaction entre Qonto, sa pièce et l’écriture proposée. Les identifiants et montants sont illustratifs ; les comportements API ont été relus dans la documentation officielle Qonto le 9 septembre 2026.
01 · Chronologie bancaire
source
Transaction Qonto
TRX-QT-8421− 1 284,40 €
Fournisseur Atelier Mistral
- Side
- debit
- Operation type
- transfer
- Devise
- EUR
- Mapping
- BANK-QT-v4
- pendingobservé, non publié
- completedsettled_at reçu
02 · Dossier de preuve
contrôle
Pièce et owner
- Transaction ID stableOK
- Montant et deviseOK
- Fournisseur ERPOK
- TVA 20 % justifiéeOK
- Owner de correctionFinance
Lecture bornée
updated_at_from · page 1/103 · Système comptable
cible
Écriture proposée
Journal banqueBQ-092
Date de valeur09/09/2026
| Compte | Débit | Crédit |
|---|---|---|
| 606300Prestation | 1 070,33 | — |
| 445660TVA déductible | 214,07 | — |
| 512100Banque Qonto | — | 1 284,40 |
Proposition équilibréeDébit = Crédit
Balance rapprochéeÉcart 0,00 €✓
Premier lot recommandé
Un compte, une fenêtre de clôture et la transaction que personne ne veut rapprocher deux fois.
Apportez son identifiant Qonto, sa pièce, la facture attendue, la règle actuelle et l’écart qui oblige encore à exporter. Le pilote doit rendre la chronologie, l’écriture, la balance et la seule reprise autorisée compréhensibles par finance et IT.
Quand le solde paraît juste
Une transaction peut être visible dans Qonto et rester inexploitable pour la clôture.
Le flux bancaire, la pièce et l’écriture n’avancent pas toujours au même rythme. Le contrat d’intégration doit préserver cette chronologie au lieu de masquer les états provisoires.
01
Statut
Le mouvement pending est comptabilisé comme définitif
La liste des transactions renvoie completed par défaut, mais pending et declined existent. Mélanger autorisation, émission et règlement peut créer une écriture prématurée ou un doublon lors de la confirmation.
02
Pièce
Le justificatif est annoncé avant d’être réellement disponible
L’upload de pièce est traité en arrière-plan. Une réponse acceptée ne suffit donc pas : le connecteur doit relire l’attachement et garder l’opération à justifier tant que le document n’est pas observable.
03
Référentiel
Une catégorie bancaire remplace la décision comptable
Catégorie Qonto, fournisseur ERP, compte général, TVA et centre de coût ont des owners différents. Une valeur inconnue doit ouvrir un écart, jamais choisir silencieusement une écriture.
Contrats d’intégration Qonto
Six contrats empêchent le relevé bancaire de devenir une comptabilité parallèle.
Qonto expose la chronologie bancaire. Votre ERP et votre logiciel comptable gardent les règles de tiers, de TVA, d’imputation et de clôture.
Le bank account reste une identité, pas un simple IBAN affiché
Organization ID, bank account ID, devise, statut et permissions effectives sont conservés pour éviter de lire le mauvais compte ou des champs non autorisés.
Chaque changement de statut enrichit la même chronologie
Transaction ID, side, operation type, montants, emitted_at, settled_at et updated_at sont rapprochés sans créer un nouvel objet à chaque lecture.
Le document possède son propre état de disponibilité
Attachment IDs, indicateurs required/lost, accès de lecture ou d’écriture et traitement différé sont suivis séparément de la transaction.
La règle comptable est versionnée et attribuée
Fournisseur, facture, compte, TVA, centre de coût et libellé cible sont décidés par leurs owners, avec une sortie explicite pour chaque valeur inconnue.
Le webhook signé déclenche une relecture bornée
Timestamp, corps brut, HMAC, event ID et type sont validés avant inbox ; le worker relit ensuite la ressource au lieu de prendre le message pour une clôture.
La balance décide si le lot peut être confirmé
Solde d’ouverture, mouvements retenus, solde de fin, rejets et écarts sont rapprochés avant publication dans le système comptable.
Méthode de clôture
Faire signer la règle qui transforme un mouvement bancaire en décision comptable.
Dawap part d’une transaction réellement difficile. Finance et IT nomment le compte, le statut exploitable, la pièce attendue, la règle de rapprochement, la date de valeur, l’owner et la sortie autorisée. Le connecteur ne généralise qu’après avoir contredit ce contrat avec des états tardifs et des données incomplètes.
Reconstruire la chronologie
Retrouver le même mouvement malgré une mise à jour de statut ou une seconde lecture.
Prouver la pièce
Distinguer upload accepté, traitement en cours, document visible et pièce encore manquante.
Expliquer l’écriture
Associer chaque champ comptable à une source, une version de règle et un owner.
Fermer la balance
Comparer solde initial, mouvements pris en compte, rejets et solde final avant publication.
Premier lot Qonto
Fermer un dossier bancaire difficile avant d’automatiser tous les comptes.
On choisit un compte, une fenêtre de clôture et une transaction qui a déjà demandé une correction. Le lot est accepté lorsque ses statuts, sa pièce, son mapping et son effet comptable peuvent être reconstruits sans ouvrir une requête technique ad hoc.
1 compte
1 période
1 transaction
5 contre-tests
1 owner finance
Sorties attendues
Carte compte–transaction–pièce–facture–écriture avec source de vérité et owner pour chaque donnée.
Inventaire des endpoints, scopes, permissions utilisateur, fenêtres, pagination, webhooks et limites applicables.
Connecteur pilote sur updated_at avec checkpoint, table d’identités et mapping comptable versionné.
Cinq contre-tests : pending confirmé, declined tardif, pièce différée, devise inconnue et replay après timeout.
Balance de lot et journal expurgé reliant transaction ID, statut, attachment ID, règle, écriture et décision.
Recette finance–IT, alertes, quarantaine, reprise ciblée, documentation et runbook de clôture.
Recette Qonto
Trois dossiers qui doivent produire une décision finance vérifiable.
Ces scénarios sont illustratifs et doivent être rejoués dans votre compte Qonto, avec vos droits et vos règles comptables. Ils ne constituent pas des résultats clients ni une intégration Qonto déjà livrée.
Une transaction pending devient completed après une première projection.
- Scénario terrain
- La première lecture voit une autorisation et la seconde un mouvement réglé avec ses dates finales. Créer deux lignes ou conserver l’écriture provisoire déformerait la clôture.
- Architecture
- Table d’identité par transaction ID, fenêtre updated_at avec recouvrement, état courant, historique de changements et projection remplaçable avant confirmation.
- Livrable
- Fixture pending–completed, règle de transition, checkpoint, test de double lecture et journal avant/après.
- Décision
- Mettre à jour le même dossier, recalculer la proposition et confirmer uniquement l’état autorisé par la finance.
- Résultat vérifiable
- Une seule écriture finale explique les deux observations et conserve les dates bancaires reçues.
L’upload est accepté mais la pièce n’est pas encore visible.
- Scénario terrain
- Le document est traité en arrière-plan. Fermer la relance sur le seul HTTP 200 annoncerait une preuve que l’API ne permet pas encore de relire.
- Architecture
- Clé X-Qonto-Idempotency-Key sur l’endpoint concerné, état requested–processing–available, relecture bornée et délai maximal de décision.
- Livrable
- Journal d’upload, attachment ID, contrôle de disponibilité, métrique d’âge et procédure d’escalade.
- Décision
- Conserver l’opération à justifier jusqu’à observation de la pièce ou classement explicite de l’échec.
- Résultat vérifiable
- La finance distingue document demandé, disponible ou perdu sans dupliquer l’upload au retry.
Le montant correspond, mais le tiers et la TVA restent ambigus.
- Scénario terrain
- Une référence bancaire rapproche plusieurs factures possibles et la catégorie Qonto ne suffit pas à choisir l’imputation. L’automatisation nominale fabriquerait une écriture plausible mais invérifiable.
- Architecture
- Règles de matching hiérarchisées, seuil d’ambiguïté, version de mapping, quarantaine et balance séparant proposé de confirmé.
- Livrable
- Matrice de règles, explication du score, cas limites, file d’écarts et export de clôture.
- Décision
- Bloquer la confirmation, attribuer l’écart au owner finance et mémoriser la décision validée sans en faire une règle universelle.
- Résultat vérifiable
- Le total non rapproché reste visible et aucune écriture ambiguë n’entre silencieusement dans la clôture.
Qonto, paiements ou finance transverse ?
Le bon owner dépend de l’événement qui engage réellement l’entreprise.
Nous connectons les comptes, transactions et justificatifs Qonto aux outils de l’entreprise. Le paiement client et la gestion de plusieurs systèmes financiers peuvent demander des connexions complémentaires.
Le dossier part d’un compte ou d’une transaction Qonto
Cette offre cadre lecture bancaire, pièces, statuts, webhooks, mapping comptable, balance et run du connecteur.
Le besoin porte sur checkout, PSP, capture ou remboursement
Le hub paiements possède la transaction marchande et son cycle avant que le règlement n’apparaisse sur le compte bancaire.
Plusieurs banques, ERP ou outils de dépenses doivent converger
Le hub finance porte le modèle unifié, les règles de clôture et les arbitrages d’architecture au-delà de Qonto.
Frontières de responsabilité
Relier Qonto aux paiements, aux factures et aux justificatifs
Une transaction bancaire ne remplace ni le paiement client, ni la facture ERP, ni la pièce documentaire.
Dawap a sécurisé chaque transition du cycle de commande 1UP Distribution : panier métier, relecture, adresses, réservation temporaire, découpage par zones, import Odoo idempotent, progression, reprise, annulation, expédition, facture et avoir. Un workflow qui distingue clairement demande reçue, stock protégé et engagement confirmé.
Le Purchase Pipeline de Ciama commence après la décision d’achat. Il rapproche commandes fournisseurs ouvertes, valeur convertie, dates dépassées, quantités commandées et reçues, produits encore attendus et partenaires qui portent l’encours. Chaque signal renvoie à l’objet source, sans créer un second registre de tâches à maintenir.
L’API Qonto expose comptes et transactions utiles au rapprochement, avec des statuts et dates qui évoluent jusqu’au règlement définitif. La méthode proposée cherche d’abord à synchroniser les mouvements, gérer doublons et pièces, afin que la comptabilité distingue une opération en attente d’un montant réellement disponible.
La réconciliation API devient utile quand chaque écart est relié à une source de vérité, à une preuve d’exécution et à une action bornée. Elle évite les resync massifs et transforme un doute sur la donnée en décision lisible. Le dispositif conserve la fenêtre, le watermark, la clé métier et le droit de correction avant tout replay ou compensation.
Une intégration API peut sembler fonctionner correctement pendant des semaines, puis générer soudainement des doublons de commandes, de paiements ou d’écritures comptables. Ce type d’incident coûte rarement seulement du temps technique. Il mobilise aussi le support, la finance et le commerce dans le run métier.
Webhook, polling et rattrapage ne servent pas le même objectif : l’un pousse le signal, l’autre contrôle la reprise. Cette carte montre comment tenir commandes, stocks et tickets sans confondre latence, quota et cohérence métier, tout en gardant un flux lisible pour le support et pour le run. Un vrai repère pour le run.
Questions fréquentes
Questions fréquentes avant une intégration Qonto API
Réponses sur transactions, pièces, authentification, pagination, webhooks et frontière avec les paiements.
01Comment connecter Qonto à un logiciel comptable ou un ERP ?
Le connecteur lit d’abord les comptes puis les transactions par bank account ID ou IBAN. Il conserve les identifiants, statuts, montants, devises et dates, rapproche facture et pièce selon une règle versionnée, puis publie uniquement la décision autorisée dans le système comptable.
02Faut-il utiliser une clé API ou OAuth 2.0 ?
La Business API prend en charge les deux selon le cas d’usage et les endpoints. OAuth permet de demander des scopes précis ; certaines actions sensibles ou destinées à plusieurs organisations l’exigent. Le cadrage vérifie endpoint, rôle utilisateur, scope et éventuelle approbation avant de choisir.
03Comment récupérer toutes les transactions sans en perdre ?
GET /v2/transactions accepte bank_account_id ou IBAN, des filtres de statut et des fenêtres updated_at. Les listes sont paginées avec page et per_page, au maximum cent éléments par page. Le connecteur conserve sa fenêtre, un recouvrement contrôlé et la clé de transaction pour dédupliquer.
04Comment traiter un justificatif envoyé à Qonto ?
L’upload sur une transaction accepte JPEG, PNG ou PDF et est traité en arrière-plan. Le flux utilise le scope attachment.write et la clé d’idempotence exigée, puis relit la ressource avec le droit adapté avant de déclarer la pièce disponible.
05Comment sécuriser les webhooks Qonto ?
Les webhooks Business API signés exposent X-Qonto-Signature avec timestamp et HMAC-SHA256. Le récepteur vérifie le corps brut et refuse un timestamp âgé de plus de cinq minutes, mémorise l’event ID, puis relit la ressource. L’abonnement demande le scope webhook plus le scope de la ressource suivie.
06Quelle différence entre Qonto API et une API de paiement ?
Qonto porte le compte bancaire, les transactions, leurs statuts, les pièces et certains flux financiers. Une API de paiement porte le checkout, l’autorisation, la capture ou le remboursement marchand. Les deux peuvent se réconcilier, mais aucun ne doit absorber les responsabilités de l’autre.
Qonto Business API · banque et comptabilité
Votre prochaine clôture peut-elle expliquer chaque transaction Qonto sans export correctif ?
Dawap peut cadrer une transaction témoin puis construire le connecteur, le mapping, la balance et la reprise qui rendent le flux Qonto défendable en production.
Cadrer mon flux Qonto