Visma API Integration
Visma is a software group from Oslo that grew across Europe by acquisition, and the products it bought keep running under their own names, with their own product architecture and their own way in. Maesn connects Visma e-conomic and Visma eAccounting on nested pages here, reaches Holded, BuchhaltungsButler and Dinero on their own, and the whole portfolio answers one REST API.
- objects readable
- 4objects readable
- objects writable
- 2objects writable
- more on demand
- 287more on demand
Three costs of a Visma integration that stop here
Integrating with more than one Visma product is not one integration done twice. Here is what each product costs on its own, and what stops at this layer.
One connection flow instead of one per product
Visma e-conomic hands out a single AppSecretToken and pairs it with a per-customer grant token on every request. Visma eAccounting emails you a client id and secret, wants a subscription key alongside them, and will not let you set the callback URL yourself. Holded does not use a redirect at all. Underneath Maesn they come out as one account key.
Which Visma a customer runs is a lookup, not research
The same eAccounting system is sold as Spiris in Sweden and as eAccounting in Norway and the Netherlands, while the Finnish products in the portfolio are not eAccounting at all and run on separate APIs. A prospect saying they are on Visma has told you the group and not the system. Maesn holds that mapping, so the answer is picked rather than investigated.
Testing four Visma markets without running four projects
A Visma eAccounting sandbox company belongs to one region and the region cannot be changed afterwards. Each Visma account carries exactly one, so testing a second market means registering a second account under a different email address. That work happens on this side, and what you get is a connection that behaves the same whichever market it came from.
What reaches your code is a REST call and an account key. Which Visma product a customer runs becomes a configuration value, and the next Visma market is a commercial decision rather than an engineering one.
A short call is usually enough to tell which Visma product your customers are on.
Which Visma systems you reach through the Maesn Unified API
Visma buys software and lets it keep running under its own name, so the portfolio is a list of products rather than a product line. This is where each one stands with Maesn right now.
Six of these answer the Maesn API today, and two of them are the same connection under two names. The rest are listed because a portfolio this wide is part of the decision, and because knowing which product a market runs is the work that comes before the integration.
One Visma API covers three markets under three different names
There is one exception to the rule that every Visma product is its own system, and it is the eAccounting family. The same target system is sold under a different brand in each of its markets, which means a connection built for one of them already reaches the others.
- SwedenSpiris
Formerly SPCS, and the reason a Swedish customer will not recognise the name eAccounting.
- NorwayVisma eAccounting
In the directory today, and the market the free trial link points at.
- NetherlandsVisma eAccounting
In the directory today, and the second market on the same credentials.
The practical consequence is that a Swedish prospect on Spiris and a Norwegian prospect on Visma eAccounting are the same integration for you. What is worth confirming per market is the endpoint level, because availability is not identical in all of them.
The portfolio around it is a different matter: Visma buys software and keeps each product on its own interface, so one vendor logo can still mean several unrelated integrations. Where a portfolio is this fragmented, one common data model is what keeps a new market from becoming a new codebase.
Tell us which country and which product, and we will confirm what is possible today.
Findity embeds expense sync in their partners' products
Findity is an expense management platform that sells 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 APIs through Maesn
A single Visma integration into a single market is a normal integration. The cost appears with the second product, because the second product shares a parent company with the first and almost nothing else.
The product research stops here
Which Visma system runs in which market, what it is called there, which API it sits on and what it hands you at registration is the work before the work. Maesn carries it, and it does not get redone the next time a prospect says they are on Visma.
Depth you can verify, per system
Each nested system gets its own coverage matrix rather than one averaged number, because the difference between them is the information. What is available on request is marked as available on request.
One integration, and it is not only Visma
The same interface that reaches Visma e-conomic reaches 30+ other ERP and accounting systems. The Visma portfolio grows on our side rather than in your codebase, and so does everything next to it.
Every Visma product runs a marketplace of its own
Most providers stop at the API. Maesn does the technical enablement and the listing, and on Visma the listing is not one listing: each product runs its own marketplace with its own audience, so the process is started per product rather than once for the group.
Technical enablement
One integration against the Unified API and one data model, identical across the Visma products and across everything else Maesn supports. Your engineers meet one interface rather than one per product.
Partnership support
Maesn initiates the listing process for the specific product, in the market where that product is actually sold, and supports the co-marketing that comes with it. The listing carries your product's name, not ours.
Per product, not per group
Visma e-conomic runs an app marketplace of its own and Visma eAccounting runs a separate one. Being listed in one says nothing about the next, which is the same fragmentation the API side has.
Per market, in practice
The products are sold under different names in different countries, and the audience of a marketplace is the audience of that market. A product live in Denmark and Sweden has been in front of two different sets of customers.
Co-marketing comes with it
The listing is the entry point rather than the whole benefit. What follows is joint visibility with the vendor, and on a portfolio this fragmented that is worth more than a directory entry, because the audience is reached product by product.
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 the specific product with you.
Two connected Visma systems, two different credential sets
The two nested Visma systems authenticate in two genuinely different ways, which is where a shared parent company stops meaning a shared architecture. Visma e-conomic uses a proprietary two-token model rather than OAuth. Visma eAccounting uses OAuth 2.0 with scopes declared up front. Neither appears on Maesn's interactive or headless authentication lists, so both run the standard redirect and neither asks your customer to pick a company. Holded, the third system in this portfolio, is on the headless list instead.
- Two-token model
- Visma e-conomic, app token plus per-customer grant
- OAuth 2.0
- Visma eAccounting, three values and a callback Visma sets
Two front doors, one implementation. Maesn holds both sets of credentials and returns one account key per connected customer.
- One set of app credentials per system
- The AppSecretToken for Visma e-conomic, and for Visma eAccounting the client id, the client secret and the subscription key. Submitted once, used for every customer you connect in that market.
- The tokens and their lifecycle
- The per-customer grant token on e-conomic is attached to later requests here. On eAccounting, refresh runs here too, which matters because that system invalidates a token silently when the user changes their password.
The silent invalidation on eAccounting is the failure mode worth planning for, because it produces no error until the next call and no notification at all. Maesn detects it and surfaces the re-authorisation, which turns an integration that quietly stopped working into a prompt your customer can act on.
- 1
Your customer starts in your product
You send them into the flow and Maesn opens the consent screen of whichever Visma system they run. It carries your application's name, because the app is registered under your company.
- 2
They authorise once
Neither nested system asks for a company selection, so the flow is a single approval. What comes back is the context later requests need, stored against the connection.
- 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 nothing in your code has to know whether it reached a two-token system or an OAuth one.
Both Visma systems stay in sync on a scheduled read
Both nested Visma systems stay in sync on a scheduled read, and it runs without asking anyone. On both, most events are marked as available on request rather than as unsupported, so an event your product depends on is a question of enablement.
Nothing you receive without arranging it first. A change inside a customer's Visma account stays invisible until something goes and reads it. Where an object's events would change your product, that is what the on demand column is for.
One scheduled read, with the same filter and the same pagination on both systems and on everything else you connect. The change-detection code is written once and pointed at a different account key, whichever Visma product sits behind it.
Underneath, the two systems page differently, and that is the kind of difference this layer exists to remove. Visma e-conomic pages by cursor across both of its APIs, so you cannot jump to a page or ask for an offset. Visma eAccounting returns 50 results per page and will hand back an incomplete set without complaining if nobody follows it. Through Maesn both answer the same offset paging, and the walking happens on this side.
Two systems that page differently still have to be read on the same schedule by the same code. One way to filter and page is what makes that possible, and the event model is where a Visma object lands the day one of these events is switched on.
What a Visma integration needs before the first call
What a Visma integration needs before the first call depends on which Visma it is. Four things hold across the connected ones, and all four are on the customer's side of the line rather than in your code.
- An active account, per product
- Both nested systems name this as their entire prerequisite list: an active Visma e-conomic account, or an active Visma eAccounting account. Worth confirming in the qualifying conversation, because there is nothing to connect without one.
- An application of your own, registered per product
- For Visma e-conomic you create an app in the developer portal and add Maesn's callback URL yourself. For Visma eAccounting the credentials arrive by email when you register, and the callback URL is the part you cannot set: you have to ask Visma to change it.
- The credentials, handed over once
- Visma e-conomic needs the AppSecretToken submitted to Maesn. Visma eAccounting needs the client id, the client secret and the subscription key. Submitted once, used for every customer you connect afterwards.
- One sandbox account per region you want to test
- Maesn's sandbox documentation marks both systems as having a free trial and as being provided by Maesn. On eAccounting the region is fixed when the sandbox company is created, and a production client id reaches a sandbox company while a sandbox client id never reaches production.
We walk through the registration for each product with you.
What the two nested Visma APIs expose today
One matrix per system, because averaging them would hide the point. Visma e-conomic reads 4 objects and writes 2, Visma eAccounting reads 2 and writes none, and the 2 objects on both lists are the same two either way.
Showing 6 of 37 objects · 25 more available on demand
| Object | Read | Create | Update | Delete | Webhook |
|---|---|---|---|---|---|
| Accounts | |||||
| Booking proposals | |||||
| Customers | |||||
| Journals | |||||
| Payments | |||||
| Suppliers |
- Supported
- live today
- On demand
- available on request
- Not available
- not offered by Visma e-conomic
Showing 2 of 37 objects · 28 more available on demand
| Object | Read | Create | Update | Delete | Webhook |
|---|---|---|---|---|---|
| Customers | |||||
| Suppliers |
- Supported
- live today
- On demand
- available on request
- Not available
- not offered by Visma eAccounting
One reading list contains the other
Visma e-conomic reads accounts, customers, journals and suppliers. Visma eAccounting reads customers and suppliers, and that is the whole list. Everything the smaller system reads, the larger one reads too, so the two are not two configurations of one product with different options switched on.
Only one of the two writes anything
Visma e-conomic creates booking proposals and payments. On Visma eAccounting, create, update and delete stand at zero across all 37 objects, so anything that has to write today writes on e-conomic. Pushing into a Swedish or Norwegian eAccounting ledger means asking for objects marked on request.
Almost nothing is off, and almost nothing is on by default
The two systems hold the two highest on-demand counts in the catalogue, 145 and 142. Those combinations are available on request rather than absent, so the useful question is which objects your use case needs: tell us, and they get enabled for the system you need them on. No object on either system has delete enabled.
Holded is in this portfolio and behaves unlike both
The third system carrying Visma as its vendor reads, creates and updates the same three objects: contacts, customers and suppliers. It also authenticates without a redirect, which neither nested system does. Same parent company, a different answer every time.
Read the two tables next to each other and the shared parent company stops explaining anything. Everything the smaller system reads, the larger one reads too, so this is not one product with different options switched on. Whatever you do pull comes back in the same shape, which is what lets one piece of your code handle both.
The columns marked on demand are the more useful half of these tables. Between them the two systems carry 287 such combinations, so the question worth asking is not what is enabled today but which objects your use case needs. That is a request rather than a roadmap item, and it is answered per system.
Tell us which objects your use case needs and we will confirm what is possible per system.
