What it takes to connect Revolut Business to your accounts package

Revolut publishes a Business API that will list your accounts and return your transactions. It is properly documented, it is free to use, and it does not require a third-party aggregator sitting between you and your own money.

It is not on every plan. API access is included on Grow, Scale and Enterprise. It is not included on the Basic plan, which is the free one, and there is no add-on that changes that.

This matters more than it sounds. A business on Basic cannot be connected to anything through the Business API, by us or by anybody else, and no amount of engineering gets around it. If you are reading this because you want a bank feed, the first thing to check is which plan you are on. It takes ten seconds in the app and it decides whether the rest of this page applies to you at all.

Revolut does not issue an API key. The setup is a certificate exchange followed by an OAuth consent, and it is deliberately more work than pasting a token into a form.

You generate a key pair on your own machine and upload the public certificate in the Business app, under APIs, Business API. Revolut gives you back a Client ID. Your application then signs a client assertion JWT with the private key, you consent to the application inside the Revolut Business app, and you exchange the resulting authorisation code for an access token against the token endpoint.

Doing this requires specific permissions on your Revolut account: Manage Integrations and Manage API under API and Integrations, and View Business under Billing. If you are not the owner of the account, somebody who is will need to grant those before you start.

The private key never leaves the machine that generated it, and the certificate you upload is a public one. That is a better arrangement than most bank integrations offer, and it is the reason the credential can be genuinely read-only and genuinely yours: you can revoke the certificate from your own settings at any moment, and whoever built the integration cannot stop you.

A Revolut Business integration runs on three separate expiries, and confusing them is where most of the trouble comes from.

The access token lasts forty minutes. The documentation returns expires_in as 2399 seconds and states the limit in words as well. Any process that holds a token for longer than that and assumes it still works will fail, and it will fail intermittently, which is worse.

The refresh token does not expire. Revolut's documentation says so explicitly. That is unusually generous and it removes the failure that ends most bank integrations, which is a credential quietly dying at three in the morning six weeks after anybody last thought about it.

The certificate is the one with a real deadline. The command in Revolut's own guide creates it with a validity of 1825 days, which is five years. That is long enough that whoever set it up will not be the person who has to renew it, which is exactly why it should be written down on the day it is created rather than discovered on the day it stops.

Reading transactions is the easy half. A list of transactions with no categories on it is a bank statement with extra steps, and plenty of integrations stop there and call it done.

The value is in what happens after the read. Transactions matched against the invoices they settle, so the money that actually landed sits beside the money that was billed. Categories that follow the chart of accounts your bookkeeper already uses, rather than a set the software invented, because a system that invents its own categories creates a reconciliation job instead of removing one. And receipts matched to the lines they belong to, so the shoebox at the end of the quarter is empty.

Done properly, the only lines a person ever looks at are the ones no rule could place. That list being short is the whole product.

This is the most common defect in software that handles bank data, and it is invisible until it is not.

Amounts should be held as integers in the smallest unit, so 18.34 euro is stored as 1834 cent, and converted to a decimal exactly once, at the point it is printed on a screen. The reason is that binary floating point cannot represent most decimal fractions: in JavaScript, 1.005 multiplied by 100 evaluates to 100.49999999999999, so the obvious way of converting a decimal amount to cents rounds it down and loses one.

One cent per transaction sounds like nothing. It is not nothing when the total is being reconciled against a bank statement that is correct to the cent, and it is the kind of error that surfaces months later as an unexplained difference nobody can find.

Nothing above is specific to Revolut except the front door. Any bank that exposes a business or open banking API can be connected, and the matching, the categorisation and the reconciliation behind it are the same work whichever bank it is. Revolut is the one written so far because a large share of small Irish businesses bank there.

To be straight about the state of it: the integration is written and the design is settled, and no client is running it yet. Revolut puts the API on Grow and above, and the businesses we work with today are on Basic, so there has been nothing to connect it to.

That means the first build is done at cost and to a date agreed in writing, and the first client is paying in patience rather than in money. Everything else we sell is live for somebody. This one is not, and saying so here is cheaper than saying it after somebody has signed.