Relier votre compte Qonto à votre logiciel de gestion

Clé API ou OAuth 2.0 : quel accès demander à Qonto ?

Qonto distingue deux situations. Pour automatiser votre propre entreprise, la clé API ou OAuth 2.0 conviennent, selon les endpoints appelés. Pour une intégration proposée à d'autres clients Qonto, la documentation oriente vers la création d'identifiants d'application et la mise en place du flux OAuth 2.0.

Deux détails d'OAuth chez Qonto piègent les intégrations. Sans le scope offline_access, aucun jeton de rafraîchissement n'est délivré et l'intégration s'arrête au bout d'une heure. Et chaque jeton de rafraîchissement ne sert qu'une fois : deux traitements qui rafraîchissent en même temps font échouer le second, d'où l'intérêt de confier le renouvellement à un seul service. Qonto précise enfin que les fonctionnalités disponibles dépendent du plan tarifaire du compte connecté, un point à vérifier dès le cadrage.

Quelles données un logiciel peut-il échanger avec Qonto ?

Qonto cite lui-même comme cas d'usage la synchronisation des transactions et des factures avec leurs justificatifs, la facture Factur-X et le virement SEPA vers un bénéficiaire de confiance. Dans une PME, cela donne par exemple les flux suivants.

1. Le rapprochement bancaire automatique. Chaque nuit, le logiciel appelle GET /v2/transactions avec le compte concerné, le filtre updated_at_from et le sens credit. Il compare la référence de chaque transaction aux factures en attente : celles qui correspondent passent en payées, les autres attendent une décision dans un écran dédié. Par défaut, seules les transactions au statut completed sont renvoyées.
2. Le justificatif qui suit la dépense. Le logiciel d'achats envoie le PDF de la facture fournisseur par POST /v2/attachments (JPEG, PNG ou PDF, un fichier par requête) et réutilise l'identifiant obtenu pour la facture fournisseur ou le virement correspondant.
3. La facture émise depuis le logiciel métier. Une intervention terminée crée une facture client par POST /v2/client_invoices, avec client, dates, IBAN de règlement et lignes (désignation, quantité, prix unitaire, taux de TVA). Pour une organisation française, Qonto produit le document au format Factur-X ; le PDF est généré en différé (la documentation conseille d'attendre une dizaine de secondes avant de le demander), et la page publique de la facture reste accessible sans authentification pendant 180 jours après l'émission, sauf annulation. Un numéro de facture déjà utilisé est refusé avec une erreur 409.
4. Le paiement des fournisseurs validés. Une facture fournisseur approuvée dans l'ERP prépare un virement SEPA, soumis aux règles détaillées plus bas.

Pour le cadre réglementaire de la facturation, voyez notre guide facture électronique 2026, et pour la suite donnée aux retards de paiement, notre page pour automatiser les relances d'impayés.

Virements SEPA par API : les garde-fous prévus par Qonto

Un virement créé par POST /v2/sepa/transfers déplace de l'argent réel, et Qonto l'encadre en conséquence. La référence de l'endpoint, consultée en octobre 2026, indique le scope OAuth payment.write et les règles suivantes.

Ces règles dictent la conception : le logiciel prépare le virement, une personne habilitée le valide, et la référence reprend le numéro de facture du fournisseur pour que le rapprochement soit immédiat de son côté.

Webhooks, limites d'appels et bac à sable

Les webhooks Qonto évitent d'interroger l'API en boucle, à condition de disposer d'un serveur réactif :

• l'abonnement se crée par POST /v2/webhook_subscriptions, pour un ou plusieurs types d'événements (transactions, virements, factures clients, cartes, etc.) et avec le scope OAuth webhook, vers une adresse publique en HTTPS qui accepte des POST ; les événements antérieurs à l'abonnement ne sont pas envoyés ;
• le serveur doit répondre par un code 2xx en 1 seconde au plus, sinon la livraison est considérée comme échouée ; Qonto conseille de stocker le message dans une file et de le traiter ensuite ;
• chaque requête porte un en-tête X-Qonto-Signature au format t=horodatage,v1=signature, une signature HMAC-SHA256 calculée sur l'horodatage et le corps brut avec le secret du webhook ;
• les échecs sont réessayés avec un délai croissant pendant quelques jours, et la documentation ne décrit pas de dédoublonnage : le logiciel reconnaît lui-même un événement déjà traité.

Côté volume, Qonto publie deux plafonds appliqués par adresse IP : 1 000 requêtes par tranche de 10 secondes et 10 000 requêtes par tranche de 10 minutes, avec une erreur 429 au-delà. Plus de 200 requêtes rejetées en 401 en une heure déclenchent aussi un ralentissement : une clé expirée qui tourne en boucle peut donc pénaliser les autres flux partant du même serveur.

Pour les tests, le bac à sable s'ouvre depuis le Developer Portal. Chaque requête y porte l'en-tête X-Qonto-Staging-Token, sur l'hôte thirdparty-sandbox.staging.qonto.co, qui n'est pas accessible directement depuis internet, et ce jeton n'est pas accepté en production.

Points de vigilance avant de brancher un compte bancaire

• Le périmètre de l'accès. Quand l'intégration n'a besoin que de lire les transactions (scope organization.read) ou de déposer des justificatifs (scope attachment.write), OAuth avec ces seuls scopes limite les dégâts possibles en cas de fuite.
• La garde des secrets. La clé API, le secret OAuth et le secret de webhook vivent dans un coffre côté serveur, jamais dans un fichier partagé ni dans une application mobile.
• Les doublons. La clé d'idempotence d'un virement, enregistrée avec la facture fournisseur, empêche un double paiement après une coupure réseau.
• Les données personnelles. Noms, IBAN et libellés de transactions sont des données personnelles dès qu'ils concernent des particuliers ou des salariés : durée de conservation, droits d'accès et journal entrent dans votre registre, comme l'explique notre guide RGPD et logiciel métier.
• Les champs dépréciés. Le champ category des transactions est déprécié au profit de cashflow_category et cashflow_subcategory : un code écrit d'après d'anciens exemples doit être relu.

Marketplace Qonto, logiciel comptable ou intégration sur mesure ?

Qonto prévoit que des éditeurs (ERP, logiciels de comptabilité, outils financiers) se connectent au nom de leurs utilisateurs et publient leur intégration sur la Marketplace Qonto, ou intègrent Qonto nativement avec Qonto Embed. Avant tout développement, vérifiez donc la Marketplace et les réglages de votre logiciel comptable : si une liaison existe et couvre vos flux, elle vous évite un code à maintenir.

Une intégration développée se justifie quand le logiciel métier lui-même doit savoir qu'un client a payé, déposer ses justificatifs ou préparer des virements selon vos règles : une entreprise de services qui facture depuis son outil d'interventions, un négociant qui règle ses fournisseurs à partir des réceptions validées dans son ERP. Le symptôme le plus fréquent est décrit sur notre page pour éliminer les doubles saisies.

Ce que YMHB Web livre sur une intégration Qonto

YMHB Web commence par le cadrage : quels flux (rapprochement, justificatifs, factures, virements), quel mode d'accès, quel plan Qonto, qui valide les virements. Le chiffrage vient ensuite, sur un périmètre écrit. Les développements se font dans le bac à sable Qonto, et la mise en service sur votre organisation, avec vos propres accès.

• un service de synchronisation qui garde la trace de chaque transaction lue, de chaque justificatif déposé et de chaque virement préparé ;
• un renouvellement centralisé des jetons OAuth, et des alertes en cas d'erreurs 401 ou 429 répétées ;
• un écran des transactions non rapprochées, traité par la comptabilité ;
• le code, déposé sur votre dépôt et documenté, et des identifiants enregistrés au nom de votre entreprise.

Le principe d'architecture est décrit sur notre page connecter ses logiciels par API.