Intégration API Revolut Business
Nous développons votre connecteur Revolut Business
Votre outil interroge l'API Revolut Business pour lire les transactions, déclencher des virements et rapprocher la trésorerie sans export bancaire.
- Équipe produit senior
- intégrations bancaires en production
- du cadrage au monitoring
À quoi sert l'API Revolut Business et pourquoi connecter Revolut à son logiciel ?
Revolut Business est une banque professionnelle en ligne avec des fonctions de change, de cartes d'équipe et de virements internationaux. Son API permet à votre application de lire les comptes et transactions, de créer des virements et de gérer les cartes, pour faire de la trésorerie une fonction de votre logiciel plutôt qu'un export relu à la main. On l'intègre dans des outils de gestion financière, des plateformes de paiement multi-devises ou des logiciels comptables qui ont besoin d'une vision en temps réel du solde et des mouvements sans connexion manuelle au portail Revolut.
Ce que nos clients construisent sur l'API Revolut
Rapprochement à l'arrivée de l'argent
TransactionCreated déclenche le lettrage montant plus référence. Plus d'export bancaire pointé en fin de mois.
Règlement fournisseurs depuis le métier
L'application prépare, un humain approuve le brouillon dans Revolut. Le logiciel ne vide pas un compte sur un bug de boucle.
Versement sans IBAN connu
Lien de versement pour une indemnité, un cachet, un remboursement. PayoutLinkStateChanged clôt le dossier.
Trésorerie multi-devises
Comptes, transactions et change exposés dans le portail dirigeant. Le taux n'est plus une cellule figée dans une feuille.
Ce que ça change dans votre trésorerie
La technique au service d'un résultat mesurable : une caisse à jour, des virements cadrés, moins d'export manuel.
Vous voyez l'argent quand il arrive
La facture est lettrée sur TransactionCreated, pas sur un relevé J+15. Les relances s'arrêtent le jour du crédit.
Un virement reste une décision humaine
Brouillon dans l'application, approbation dans Revolut. C'est la frontière qu'un dirigeant veut voir sur une sortie de fonds.
Moins de doubles virements
request_id dérivé de la facture, plus un verrou au-delà des 2 semaines de mémorisation Revolut. Un timeout ne paie pas deux fois.
Une clôture plus courte
Les écritures arrivent déjà rattachées. Le comptable arrête de reconstituer les flux à partir d'un CSV.
Comment nous livrons votre connecteur Revolut
Cadrage
Business API, pas Merchant. Lecture ou virement, scope PAY, liste blanche IP. On écarte READ_SENSITIVE_CARD_DATA si le produit n'en a pas besoin.
Développement
Client JWT, access_token renouvelé avant 40 minutes, request_id métier, signature v1.{timestamp}.{corps} avec fenêtre de 5 minutes.
Recette
Vecteur de signature officiel, simulations sandbox (complete, revert, decline, fail), 400 sur request_id dupliqué traité comme un succès.
Monitoring
Alertes sur événement non traité, journal des virements, tableau de bord de santé. L'endpoint des échecs webhook est le filet, pas une option.
Ce que permet l'API Revolut Business
- Comptes et transactions
- Lecture des comptes et de l'historique. Pagination temporelle (from, to, count jusqu'à 1 000), pas un curseur : les égalités d'horodatage se gèrent.
- Virements et brouillons
- POST /pay avec request_id. Les brouillons matérialisent la validation humaine : l'application prépare, un habilité approuve dans Revolut.
- Liens de versement
- Payer quelqu'un dont vous n'avez pas l'IBAN. PayoutLinkCreated et PayoutLinkStateChanged suivent l'encaissement effectif.
- Webhooks v2
- Quatre types seulement, 10 webhooks maximum. TransactionCreated et TransactionStateChanged suffisent au rapprochement, le reste se balaie.
Le vocabulaire de l'API Revolut Business
- private_key_jwt
- Assertion signée avec votre clé privée. iss est le domaine de l'URI de redirection, sans https://. sub est le client_id, aud vaut https://revolut.com. Le corps d'échange est du formulaire, pas du JSON.
- request_id
- Identifiant d'idempotence dans le corps de POST /pay, pas un en-tête. Mémorisé 2 semaines. Un doublon renvoie 400 Bad Request, pas 409.
- Revolut-Signature
- v1=<hex>, HMAC-SHA256 de v1.{Revolut-Request-Timestamp}.{corps brut}. Fenêtre de 5 minutes. Pendant une rotation, plusieurs signatures, une suffit.
- READ_SENSITIVE_CARD_DATA
- Scope cartes. Sans liste blanche d'IP, vous perdez l'accès à tous les endpoints de la Business API, pas seulement aux cartes. Si le produit n'en a pas besoin, ne pas le demander.
- access_token 40 minutes
- Un 401 en milieu de job est un cas nominal. Le refresh_token, d'après la documentation, n'expire pas : la durée réelle du consentement se confirme au cadrage.
- Business vs Merchant
- Business : b2b.revolut.com, JWT, TransactionCreated. Merchant : merchant.revolut.com, encaissement, ORDER_COMPLETED. Même domaine développeur, deux produits.
Les contraintes réelles de l'API Revolut Business
Ce n'est pas la Merchant API
Hôtes, scopes et événements diffèrent. Confondre les deux est l'erreur de cadrage la plus courante : on encaisse d'un côté, on lit le compte de l'autre. Modules, secrets et routes de webhook restent séparés.
Idempotence limitée à 2 semaines
Rejouer un request_id après 2 semaines peut créer un second virement. Un 400 sur doublon est un succès, pas une erreur de validation. On persiste la correspondance dès la réponse : la recherche par request_id tient 14 jours.
Le scope carte peut tout couper
READ_SENSITIVE_CARD_DATA sans liste blanche d'IP bloque l'accès à toute la Business API. C'est un piège de configuration, pas un refus localisé à un endpoint.
Quatre événements, débit non publié
Pas d'événement de solde, de carte ni de contrepartie : le complément se balaie. Aucune limite de débit n'est publiée. L'endpoint des webhooks en échec est le filet, la retentative n'étant pas documentée de façon fiable.
Business API ou Merchant API ?
Deux produits, un même domaine développeur. Le bon dépend de si vous lisez un compte ou si vous encaissez.
| Critère | Business APILe compte | Merchant APIL'encaissement |
|---|---|---|
| Hôte | b2b.revolut.com/api/1.0 | merchant.revolut.com |
| Authentification | JWT d'assertion, scopes READ WRITE PAY | Clé marchand, en-tête de version |
| Événements | TransactionCreated, PayoutLink* | ORDER_COMPLETED, DISPUTE_WON |
| Sortie de fonds | POST /pay, brouillons, liens | Remboursement d'une commande |
| Idempotence | request_id, 2 semaines, 400 sur doublon | Propre à l'encaissement |
| Signature webhook | v1.{timestamp}.{corps}, HMAC | Même mécanisme, autres événements |
| Le bon cas | Trésorerie, virements, rapprochement | Checkout, abonnement, litige carte |
Les deux se combinent sur un même produit, avec des modules distincts. Cette page couvre la Business API. L'encaissement en ligne se cadre à part.
Ce que nous mesurons sur une intégration Revolut
Les autres API bancaires
Si tous vos comptes ne sont pas chez Revolut, ces options se discutent au cadrage.
Revolut BusinessNous développons votre connecteur Revolut BusinessCette page
QontoBanque professionnelle française, API directe, justificatifs et virements SEPA.Open bankingBridge, Powens ou Tink : plusieurs banques couvertes, données plus pauvres, consentement à renouveler.On combine Revolut avec
La stack qui entoure Revolut Business sur nos projets.
Intégration Revolut : vos questions
Trois étapes. D'abord la paire de clés, le certificat public dans le portail Revolut Business, et un client qui signe une assertion JWT (iss = domaine sans schéma, corps d'échange en formulaire). Ensuite un connecteur qui renouvelle l'access_token avant 40 minutes, lit les transactions par fenêtres temporelles, et pose un request_id dérivé de la facture sur chaque POST /pay. Enfin les webhooks v2 : HMAC de v1.{timestamp}.{corps brut}, rejet hors fenêtre de 5 minutes, plusieurs signatures pendant une rotation. La partie sensible n'est pas l'appel, c'est de ne pas confondre Business et Merchant, et de persister la correspondance request_id dès la réponse.
Un premier flux utile, typiquement synchroniser les transactions vers un tableau de bord, se livre en deux à trois semaines. Une chaîne avec virements, brouillons, liens de versement et rapprochement demande plutôt six à huit semaines. Le cadrage tranche d'abord Business API ou Merchant API, et écarte READ_SENSITIVE_CARD_DATA si les détails de carte ne sont pas nécessaires. Nous donnons une estimation ferme avant de commencer.
La Business API vit sur b2b.revolut.com/api/1.0, s'authentifie par assertion JWT, et parle de TransactionCreated, de virements et de comptes. La Merchant API vit sur merchant.revolut.com, encaisse en ligne, et parle de ORDER_COMPLETED, ORDER_AUTHORISED, DISPUTE_WON. Le mécanisme de signature de webhook est proche, ce qui trompe. Cette page couvre le compte. Si vous encaissez des clients en ligne, c'est un autre connecteur, d'autres secrets, d'autres routes.
Dériver request_id de l'intention (virement:{facture_fournisseur_id}), jamais un UUID régénéré à chaque essai. Persister le couple request_id plus identifiant de transaction dès la réponse, parce que GET /transactions filtré par request_id n'accepte que 14 jours. Traiter un 400 « duplicate request_id » comme un succès : relire la transaction dans la fenêtre, continuer. Au-delà de 2 semaines, Revolut peut créer un second paiement : le verrou applicatif couvre cette fenêtre. C'est le bug le plus concret de cette API.
Oui. Nous poussons les transactions Revolut vers Pennylane avec la référence de facture, et un contrôle de cohérence périodique signale l'écart, sans correction silencieuse. Qonto se combine quand une partie des comptes est ailleurs : l'API Qonto pour ces comptes, Revolut pour les siens, éventuellement l'agrégation DSP2 pour le reste. Ce n'est pas un choix exclusif, c'est une carte des comptes posée au cadrage. Une écriture bancaire ne se répare pas dans le dos du comptable.
Un projet d'intégration Revolut ?
Parlons-en. 30 minutes pour cadrer compte et virements, vérifier ce que l'API permet vraiment et vous dire franchement ce qui est faisable.
Parler de mon projet Revolut