Dinero API Integration
Dinero is a cloud accounting platform for small businesses in Denmark, owned by Visma and used by more than 80.000 Danish companies. It covers invoicing, bookkeeping, expenses, VAT and Danish e-invoicing. Connect it through Maesn and you reach it with the same REST API and the same data model as every other supported system.
A Dinero integration in days
Dinero runs on a plain REST API, so the requests are not the work. The work sits around them: which of Dinero's two authorisation worlds you build against, which company a call belongs to, and whether the customer in front of you is on a plan that lets the API answer at all. All three are settled before you write a line.
Your customer picks the company while connecting
Visma Connect authorises the user rather than the company, so a Danish bookkeeper reaches every client organisation through one login. Each request carries the organisation in its path, and picking the wrong one returns a 403 rather than an empty result. Dinero is one of the systems on Maesn's interactive authentication flow: your customer chooses the company during the connection, the choice is stored, and nothing in your code has to send it again.
You never choose between Dinero's two routes
Dinero's own getting-started describes two different and separate authorisation systems. Visma Connect OAuth is the route for a product that connects other companies' accounts, and a personal API key is the route for a company automating its own books. Both reach the same REST surface, each needs its own credentials, and only the Visma Connect route can receive Dinero's event. Maesn runs that route, so the choice is settled once for your product and does not come back with each new customer.
A test environment before Dinero provides one
Dinero has no dedicated developer sandbox. You build against a real organisation, the API answers only for one on an active Pro or Total licence, and creating a Dinero test account normally means being registered in Denmark. The team behind your Visma Connect application also has to carry Denmark as its country, which in practice needs a Danish CVR number, or the Dinero scopes never appear in the list to apply for. Maesn provides a sandbox for every system it supports, so your team starts building while the Danish paperwork is still in progress.
What is left is the part you wanted: read the chart of accounts and the tax codes, post a booking and read it back, and point the same code at the next system.
A short call is usually enough to tell whether Maesn fits your use case.
Findity's customers each connect their own accounting system
Findity is an expense management platform that ships white-label and through an API, so its customers reach accounting systems through Findity rather than directly. That is the shape Dinero's connect step exists for: not one company wiring up one ledger, but many end customers each choosing the organisation the connection is for.
“Maesn has helped us build integrations with accounting systems, allowing us to focus on other priorities in our roadmap. We are especially pleased with the support we have received whenever we needed extended functionality in an integration that Maesn has arranged for us.”
Three reasons to reach the Dinero API through Maesn
Building against Dinero directly is a fair choice for one system. The question is what carries over to the second, and here almost none of it does.
The Danish specifics stay on this side
Purchase vouchers, the kassekladde, contacts that become debtors only after a sale, VAT codes rather than percentages, EAN numbers and MitID for electronic invoicing. None of that is difficult once you know it, and all of it is Dinero-shaped and Danish-shaped. Through Maesn it arrives in the same model as every other system you connect, so it stays knowledge you acquire once and never becomes vocabulary your codebase has to carry.
Three Visma products, three routes
Dinero sits in the same portfolio as Visma e-conomic and Visma eAccounting, and both are already connected here. Sharing an owner does not make them alike: e-conomic connects on a two-token model, eAccounting on OAuth, and Dinero through Visma Connect with a company chosen along the way. Those three differences stay on this layer instead of becoming three implementations in your product.
One integration, every system after it
Once Dinero is connected, the systems your Danish customers ask for next are reachable on the same interface, with the same account key mechanism and the same objects. A customer who moves from Dinero to a larger ledger does not become a second integration project, and neither does the first customer who arrives from Sweden or Germany.
Dinero is the third product from the same portfolio on this interface, after the Visma systems already connected here. They are not variants of one another: the two nested products authenticate and page differently from Dinero and from each other, which is exactly the work this layer exists to absorb. Whatever comes back arrives in the shared common data model, so a booking posted to a Danish ledger has the same shape as one posted anywhere else.
A Dinero listing that starts with real traffic
Dinero lists integrations on a public directory, and what it asks for is a product that is already running rather than a plan or a fee. Maesn does the technical enablement and goes through the listing with you.
Maesn builds and runs the connection
The Visma Connect application, the scopes, the company resolution and the token lifecycle are ours. What you integrate is one REST API that behaves the same for Dinero as for everything else.
You keep the customer relationship
The listing carries your product, your logo and your description. Maesn does not appear in the directory in your place, and the Pro or Total licence the API needs stays between your customer and Dinero.
Run real traffic
Dinero reviews actual API usage rather than a submission. That means handling the error cases properly, and specifically stopping an integration that keeps failing rather than letting it retry into a wall.
Ask for the review
You send Dinero your client id and the window in which the traffic ran, and they look at what your integration actually did. The outcome is a yes or a no rather than a score.
Submit the listing
After a pass, a short form carries the logo, the website, the description and a contact address, and the integration appears on Dinero's public directory where Danish businesses go looking.
There is no tier ladder here and no partner fee: the Pro or Total licence the API needs is the customer's, and Dinero charges the integrator nothing for the listing. The condition that does bite is the first one, because Dinero limits access for integrations that use the API wastefully. What gets reviewed is how the integration behaves.
We prepare the technical side and go through the review with you.
Dinero authorises a person, so the company is a choice
Dinero authenticates through Visma Connect, the same authorisation service other Visma products use, and the interesting part is not the OAuth dance. It is that the authorisation belongs to a person who may hold several companies, and every single request has to say which one it means.
- Visma Connect OAuth 2.0
- Products connecting other companies' Dinero accounts. Authorisation code with PKCE, read and write scopes plus offline access for refresh.
- Dinero API key
- Dinero's separate route for a company automating its own books, needing a client id, a client secret and an organisation-specific key at once. Maesn's setup guide documents the Visma Connect route.
Whichever way a system authenticates, what reaches your code is a Maesn API key plus an account key. Dinero's organisation, its token lifetime and its refresh behaviour all sit behind that pair.
- Access tokens last 60 minutes
- The same in both routes. Maesn's setup guide sets the lifetime explicitly rather than inheriting a default, so the refresh cadence is a known quantity from the start.
- Refresh tokens are configured re-use, not one-time
- Visma Connect offers both. With one-time tokens, redeeming an already used token invalidates the whole authorisation and the customer has to authorise again. Maesn's setup guide selects re-use with a 365 day lifetime, so that failure mode is designed out at registration rather than caught at runtime.
- A re-authorisation once a year
- The other side of a 365 day refresh token: after a year the customer sees the consent screen again. Nothing breaks silently, the calls simply stop being authorised until they click, which makes it a date to put in front of an account manager rather than an incident.
The company choice is the step to design your connect experience around. A mismatched organisation is the most common failure on this API, and it surfaces at request time rather than at connection time, which inverts the usual order: the connection looks successful and the first real call does not.
- 1
They authorise at Visma Connect
Your customer signs in with their Visma account and grants the read and write scopes your application asked for. The consent screen shows your application name, so what you registered is what a Danish business owner reads before agreeing.
- 2
They choose the company
Because the authorisation covers a person rather than a company, the accessible organisations are discovered afterwards and presented as a choice. Your customer selects the one this connection is for, on a page you can style as your own.
- 3
You receive an account key
Maesn stores the connection and hands back an account key. From then on the organisation travels with that key, and requests look the same as for every other system you have connected.
Most authentication problems are about getting a credential. Dinero’s is about what the credential points at, which is a different question and it survives the OAuth being finished. Unified authentication is where the company selection lives: it is a documented flow for the systems that need one, the selection page can carry your own branding, and the account key you get back behaves the same whether the system behind it asked your customer to choose a company or nothing at all.
Change detection runs on a schedule you control
Dinero publishes exactly one native event, and no object carries an enabled webhook over this connection today. Those are two statements about two different things: what the vendor ships, and what arrives here.
One event, on entries. Dinero introduced it in August 2024, still describes it as being in a test phase, and offers it only to integrations that authenticate through Visma Connect. Everything else inside a customer's account changes without announcing it.
One scheduled read, with the same filter and the same pagination you use for every other system. Dinero's own answer for integrations without the event has the same shape: ask the list endpoints what changed since a given time. The difference is that here you write it once.
Detection by reading rather than by push makes freshness a question of interval, and that is a trade worth making deliberately. It also has an advantage a push does not: a scheduled read catches up cleanly after an outage, where a missed event is simply gone. Dinero enforces 100 requests a minute per organisation since April 2026, so the interval is a real budget rather than a free dial.
A system you have to poll turns change detection into code you own, and on Dinero that code has a budget: you write the loop, then another for the next system with its own filter syntax, its own page size and its own idea of what a timestamp means. One way to filter and page removes that repetition, and it matters more here than usual because Dinero counts requests: a hundred a minute per organisation, enforced since April 2026. What you handle in the event model and what you pull on a schedule stay two paths, and on Dinero today only the second one runs.
What a Dinero connection asks for up front
Four conditions decide whether a Dinero connection can be made at all. Two are yours to arrange once, and two sit with each customer.
- A Visma Connect application, approved for Dinero
- You register the application in Visma Connect and apply for Dinero's read and write scopes. The internal scope is rejected on principle, so it is not worth applying for. Approval or rejection is a manual step at Dinero rather than a switch you flip.
- A team registered in Denmark
- Maesn's own setup guide is explicit about it: if the Visma Connect team country is not Denmark, Dinero's scopes do not appear in the list at all. It is the first thing to check when the scopes seem to be missing.
- A client id that identifies your company
- Dinero approves applications whose client id names the company behind the integration. A placeholder is fine while testing and is rejected for production, so the id is worth choosing properly at the start.
- Each customer on a Pro or Total licence
- The API answers only for organisations on an active Pro or Total licence. Without one, the organisation list is the single endpoint that still answers, and it carries the subscription status, so the condition can be checked before a connection is attempted. It sits with your customer rather than with you, which makes it an onboarding question.
We walk through the application and the scopes with you.
One contact list, and two ways to guard an update
Two Dinero decisions reach your code before you map anything: how it tells a buyer from a seller, and which field it uses to stop two writers from overwriting each other.
Customers and suppliers are not two lists
Dinero keeps one contact list and marks entries as debtor or creditor, flags that turn true only once a sale or a purchase has happened. There is no separate customer object upstream to expose, so plan your matching around contacts rather than around two directories.
Concurrency comes as a Timestamp or a Version
Dinero guards updates with optimistic concurrency, and the field is not the same everywhere. Invoices, vouchers, credit notes, reminders, trade offers and payments take back the Timestamp you last read, and a stale one is rejected instead of silently overwriting someone. Ledger items do the same job with a Version field, and they also have to be posted in order for a single organisation. Both are the sort of rule that surfaces in production rather than in a first test.
Both are the kind of thing that is obvious once you know it and expensive on the day you do not. The contact list decides where the customer and supplier distinction lives, and on Dinero that answer is your side, because the flags upstream only become true after a sale or a purchase has been booked. The concurrency field decides what a write has to carry, and it is not one field: a document sends back the Timestamp it was read with, a ledger item sends a Version.
Posting is where the two meet. A booking that goes in has to name accounts from the chart you read, carry the tax code Dinero expects instead of a percentage, and arrive in order for a single organisation. Through Maesn each of those is the same call it is on every other connected system, so the Danish specifics stay knowledge you acquire once.
Tell us which objects your use case needs and we will confirm what is possible.