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 supports each of them as an integration of its own, and every system that is connected answers the same REST API.
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 has no OAuth redirect and works from a key the customer generates. 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 three Visma markets without running three 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. Maesn does that work, 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.
Of the products above, 7 answer the Maesn API today, on 6 target systems, because Spiris and Visma eAccounting are one 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.
The differences stop at this layer
Two credential models, two paging models and a different partner process per product, all answered through one account key and one data model. Which Visma a customer runs stays a configuration value in your code instead of a second implementation.
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.
Visma e-conomic and Visma eAccounting, two different credential sets
Visma e-conomic and Visma eAccounting 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: one token identifies your application, a second one is issued per customer. Visma eAccounting uses OAuth 2.0 with scopes declared up front. Your customer meets one consent screen either way, and your code meets one account key.
- 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 stored by Maesn and attached to every later request. On eAccounting, Maesn also runs the refresh, 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
One approval is the whole step, and Maesn resolves whatever the system needs alongside it. 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.
Visma e-conomic and Visma eAccounting sync on a scheduled read
Visma e-conomic and Visma eAccounting both stay in sync on a scheduled read, and it runs without asking anyone. Events are enabled per object when a use case needs one, so an event your product depends on is a conversation and not a dead end.
A change inside a customer's Visma account stays invisible until something reads it, which is true of most accounting systems and is the reason a scheduled read exists at all. Where an object's events would change your product, tell us and we enable them for that system.
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 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
- Both systems offer a free trial account, which is what a proof of concept runs on. 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.
