Visma e-conomic API Integration
Visma e-conomic is a cloud accounting platform used by SMEs and accounting firms in Denmark and Norway, covering invoicing, VAT, bank reconciliation and reporting. It is also the Visma product that authenticates least like the others: two proprietary tokens on every request, two active APIs underneath, and cursor paging on both of them. Maesn puts one REST interface in front of all of it.
Two e-conomic tokens per request, and neither one is yours to hold
Three things about Visma e-conomic cost time before you write a line of business logic, and all three stop at this layer.
A proprietary auth model, behind a standard flow
Visma e-conomic does not use OAuth. Every call carries an X-AppSecretToken that identifies your application and an X-AgreementGrantToken that belongs to one customer, and the second has to be obtained, stored and attached per connection. Maesn runs that flow, so your users see the same connect experience as everywhere else and your code holds one account key.
One interface over a system with two of them
Visma e-conomic runs a REST API and an OpenAPI at the same time, with different pagination behaviour and with functionality divided across them. Working directly means knowing which of the two answers which endpoint, and keeping that knowledge current. Through Maesn the split is not visible: one interface, one shape, and the routing happens on this side.
Creating a record without the pre-fetch chain
Creating an object in Visma e-conomic requires references that have to be fetched per tenant first: layout, payment terms, VAT zone, currency and the ledger account. Miss one and the write fails rather than degrades. Maesn resolves them in the background, so a create stays a create rather than a sequence of lookups you maintain, and a new tenant needs no mapping pass of its own.
What reaches your code is a REST call and an account key. The tokens, the two APIs and the reference chain stay on this side, and the next accounting system you support arrives on the same interface.
A short call is usually enough to tell whether Maesn fits your use case.
Findity embeds expense sync in their partners' products
Findity is an expense management platform selling white-label and API products, so their accounting integrations ship inside someone else's software rather than in their own.
“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 Visma e-conomic API through Maesn
Visma e-conomic on its own is a manageable integration. It stops being manageable at the second Nordic system, because the next one shares a parent company with this one and none of its mechanics.
The auth model is absorbed, not documented
A two-token model costs little to understand and something to maintain, and the maintenance multiplies with every additional connection shape in one codebase. Maesn holds the app token and the per-customer grant, and hands your code the same account key it gets everywhere else.
Two APIs, one interface
e-conomic runs a REST surface and an older one side by side, and which functionality sits where is not something your product should have to track. Maesn reads from both and answers on one interface, so a capability moving between them is our migration rather than yours.
One integration, and it is not only e-conomic
The same interface reaches Visma eAccounting, Holded and 30+ other ERP and accounting systems. A Danish customer today and a Dutch one next quarter are a configuration change rather than a project, and the second system costs a fraction of the first.
Visma e-conomic runs a marketplace the other Visma products do not
Most providers stop at the API. Visma e-conomic runs an app marketplace of its own, separate from the marketplaces of the other Visma products, and getting into it is a process rather than a form.
Technical enablement
One integration against the Unified API and one data model, identical for Visma e-conomic and for everything else Maesn supports. Your engineers meet one interface rather than one per product.
Partnership support
Maesn initiates the listing for Visma e-conomic specifically, in the markets where this product is actually sold, and supports the co-marketing that comes with it. The listing carries your product's name rather than ours.
A marketplace of its own
Visma e-conomic's marketplace is not the eAccounting one and not a group-wide directory. Being present in it says nothing about the other Visma products, which is the same fragmentation the API side has.
A Nordic audience
The businesses reachable through this marketplace are the ones running e-conomic, which means Denmark and Norway rather than every market Visma operates in. A listing here therefore reaches fewer companies than the group's size suggests, and closer to the ones a Danish or Norwegian use case is built for.
Co-marketing in two markets
The entry is the starting point rather than the whole benefit. What follows is joint visibility with Visma in Denmark and Norway, which is where a listing turns into pipeline rather than a directory row that nobody scrolls to.
The integration runs under your product's name, and the listing is yours rather than ours. Maesn is the layer behind it.
We initiate the process for this product with you.
A Visma e-conomic request carries an app token and a customer grant
Visma e-conomic is the one connected Visma system that does not speak OAuth, and the difference is visible on every single request rather than only at connection time. Two headers travel together: X-AppSecretToken identifies your application and is the same for all your customers, X-AgreementGrantToken identifies one customer's agreement and is different for each of them. The flow is a plain redirect with no company to pick, because the agreement a grant belongs to is the one your customer is signed in to.
- Two-token model
- App token plus a per-customer agreement grant
- The application token
- The AppSecretToken from your developer portal app, submitted once and attached to every request Maesn makes on your behalf. It never reaches your runtime.
- The per-customer grant
- The agreement grant token belongs to one customer and is stored against that connection. Your code addresses a customer by account key and never sees which grant token stands behind it.
The practical value of absorbing this one is less the tokens than the uniformity. A team that supports Visma e-conomic and one OAuth system directly maintains two connection models, two refresh behaviours and two failure modes. Through Maesn both are the same three lines.
- 1
Your customer starts in your product
You send them into the flow and Maesn opens the Visma e-conomic consent screen. It carries your application's name, because the app is registered under your company.
- 2
They approve the agreement
Approval produces the agreement grant token for that customer. There is nothing to pick along the way, so the grant lands on the agreement they are signed in to and the flow returns straight away.
- 3
You work with one account key
Maesn stores the connection and returns an account key. Every request then carries your Maesn API key plus that account key, and the two-token model never appears in your code.
A proprietary token model is not difficult on its own. It becomes expensive when it is the fourth connection shape in one codebase, each with its own refresh behaviour and its own way of failing. Unified authentication is what makes this a one-time cost: the consent screen, the token storage and the account key behave here exactly as they do on a system that authenticates with nothing but a key.
Visma e-conomic events are available on request
Visma e-conomic can push events, and none is switched on for this connection today. On most objects the event is marked as available on request, so this is a question of enablement and not of what the system supports.
Nothing you receive without arranging it first. A change inside a customer's Visma e-conomic account stays invisible until something reads it, even though the system itself is capable of notifying.
One scheduled read, on the same filter and the same pagination as every other system you connect. Where an object's events would change your product, they can be enabled for that object.
The pagination is the part worth knowing about here. e-conomic's REST surface and its older API both page by cursor, so there is no jumping to a page and no limit and offset: reaching deep into a dataset means walking everything in front of it. Through Maesn both answer ordinary offset paging and the walking happens on this side.
Reading on a schedule is where a per-system integration shows its cost most plainly, because every system pages differently and this one pages by cursor on both of its APIs. One way to filter and page removes that, and the event model is where a Visma e-conomic object lands the day one of these events is switched on.
What a Visma e-conomic integration needs before the first call
Visma e-conomic names exactly one prerequisite in its documentation, and the rest of this list is the work that follows it. None of it is code.
- An active Visma e-conomic account
- The documentation's entire prerequisite list is one line: an active Visma e-conomic account. Worth confirming in the qualifying conversation, because there is nothing to connect without one.
- An app in the Visma e-conomic developer portal
- You log in to the developer portal, create an application and add Maesn's callback URL to it. The app is registered under your company, so the consent screen your customer sees carries your name rather than ours.
- The AppSecretToken, handed to Maesn once
- One value, submitted to your Maesn contact and then used for every customer you connect. The per-customer grant token is obtained during the connection rather than supplied by you.
- A test account before a customer sees the flow
- Maesn's sandbox documentation marks Visma e-conomic as having a free trial and as being provided by Maesn, so both routes are open. Using one first is worth it, because the reference chain behind a create is the part a direct build usually discovers late.
We walk through the developer portal registration with you.
One shape for e-conomic, and for the next Nordic system
What a connection reads here is the ledger side of a Danish and Norwegian accounting platform, and what makes it worth building against is that the next system in that region answers in the same shape.
Named objects rather than a count
Accounts, customers, journals and suppliers are enabled for reading, and booking proposals and payments for writing. The rest of the matrix is on demand, which means it is switched on when a use case needs it rather than that it is unavailable.
Corrections are new records
A record here is not amended in place, so a product that keeps figures in step writes a correcting document rather than editing the original. Accounting practice works the same way, which is why this is a design decision to take early rather than a limitation to work around.
A booked invoice is final
Visma e-conomic separates invoices into drafts and booked, and once booked an invoice cannot be changed: a correction is a credit note. That is the system's model rather than a restriction of this connection, and it is the reason a correction flow looks different here than on a system that allows an edit in place.
The procurement objects sit outside this system
Goods receipts, purchase orders and their lines are not part of what e-conomic exposes, and a trial balance is assembled from the ledger rather than served as its own object. Where a product needs those, the same interface reaches the systems that do carry them.
What is not switched on yet is a request rather than a refusal. Those objects are ones nobody has needed on this connection so far, and the way to change that is to say which object your use case reads or writes.
Whatever you do pull arrives in the same common data model as every other connected system, which is the part that makes a second Nordic system cheap rather than a second project. The rest of the portfolio sits on the Visma API page.
Tell us which objects your use case needs and we will confirm what is possible.
