Visma eAccounting API Integration
Visma eAccounting is a cloud accounting platform for small businesses, and it is one system sold under a different name in each of its markets: eAccounting in Norway and the Netherlands, Spiris in Sweden. One API covers all of them, which means a connection built for one market already reaches the others. Maesn holds the token lifecycle, the paging and the regional setup behind one REST interface.
Scopes, paging and sandboxes decide what a Visma eAccounting integration costs
Three things about Visma eAccounting decide how much work an integration turns into, and none of them appear in the first successful call. All three stop at this layer.
Visma eAccounting OAuth lifecycle, fully managed by Maesn
Visma eAccounting wants its scopes declared precisely and before the first customer connects, rather than requested as your product grows into them. The three credentials and the per-tenant refresh sit on this side, so what reaches your code is a REST call and an account key instead of a token lifecycle to run per customer.
Visma eAccounting pagination handled automatically
The system returns 50 results per page by default and does not object if nobody asks for the rest. A sync written without explicit paging returns an incomplete set and reports success, which is the worst shape a data bug can take. Maesn pages every collection endpoint, so what arrives is the whole set.
One sandbox per region, handled without a second project
A sandbox company belongs to one region and the region cannot be changed after it is created, and each Visma account carries exactly one. Testing a second market means registering a second account under a different email address. That work sits on this side, and what you get is a connection that behaves the same in every market.
What reaches your code is a REST call and an account key. The scopes, the refresh and the regional setup stay here, and a Swedish customer is the same integration as a Norwegian one.
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 eAccounting API through Maesn
The first successful call against Visma eAccounting comes quickly. The cost arrives in the second year, when tokens have expired in ways nobody was told about and a sync has been returning most of the data rather than all of it.
Complete pages, not the first fifty records
A read that stops after the default page returns a valid response and part of the data, and nothing in the payload marks it as incomplete. Maesn pages every collection endpoint on this side, so what arrives in your product is the whole set rather than the first page of it.
All regional variants, one integration
The system is sold as eAccounting in Norway and the Netherlands and as Spiris in Sweden, and one connection reaches all of them. A customer who names the local brand is the same integration as one who names the other, so entering another of its markets is a lookup rather than a project.
One integration, and it is not only eAccounting
The same interface reaches Visma e-conomic, Holded and 30+ other ERP and accounting systems. A market that turns out to run a different product is a connection change rather than a project.
The Visma eAccounting names change per market, the connection does not
Visma sells this system under a different name in each market it reaches. Maesn covers every one of those variants through the same connection, so the name a customer uses is a lookup rather than a second integration to build.
Maesn reaches all of them through one connection: eAccounting in the Netherlands and Norway, and Spiris, which used to be called SPCS, in Sweden. A Swedish prospect who says they run Spiris and a Norwegian one who says they run eAccounting are the same connection for you. What is worth confirming is the endpoint level: availability is not identical in every market, so name the market together with the objects your use case needs.
Three markets on one connection is the reach, and the brand name is the only thing that changes between them. The rest of the portfolio sits on the Visma API page.
Tell us which country your customers are in and we will confirm what is possible today.
Visma eAccounting scopes are declared before the first customer connects
Visma eAccounting authenticates with OAuth 2.0, and one detail makes it different from the OAuth systems next to it: the scopes have to be declared precisely and up front rather than requested as you go, so what your application can reach is decided before the first customer connects. The company selection sits on Visma's side of the flow, and the vendor recommends forcing that selector rather than accepting whichever company the user already had open.
- OAuth 2.0
- Scopes declared up front, three values submitted once
- Three credentials and the scope declaration
- Client id, client secret and subscription key, submitted once and used for every customer in that market. The scope set is declared with them rather than negotiated per connection.
- The refresh, per tenant
- Token refresh runs per tenant on this side, so the lifecycle is not something your product schedules or stores per customer.
Declaring scopes up front is worth planning around rather than working around. Widening them later means going back to every connected customer for a fresh approval, so the question of what your product might need in a year belongs in the conversation before the first one connects.
- 1
Your customer starts in your product
You send them into the flow and Maesn opens the Visma eAccounting consent screen. It carries your application's name, because the application is registered under your company.
- 2
They approve the declared scopes
The consent screen shows what was declared up front, and Visma also asks which company the connection is for. The request forces that selector rather than accepting the company the user already had open.
- 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, whichever of the regional brands the customer actually runs.
Declaring scopes up front is worth planning around rather than working around, because widening them later means going back to every connected customer for a fresh approval. Unified authentication is where that declaration and the per-tenant refresh sit, in the same shape on every connected system rather than once per vendor.
What a Visma eAccounting integration needs before the first call
Visma eAccounting needs more from you before the first call than most systems in the catalogue, and one of the steps is not yours to take. None of it is code.
- An active Visma eAccounting account
- The documentation's entire prerequisite list is one line: an active account. Worth confirming in the qualifying conversation, because there is nothing to connect without one.
- A callback URL that Visma has to change for you
- The credentials arrive by email when you register, and the callback URL is the part you cannot set yourself. You have to contact Visma and ask them to point it at Maesn's callback address. It is a short request and a real dependency, so it belongs early in the plan rather than on the day of launch.
- Three values, handed to Maesn once
- The client id, the client secret and the subscription key together. Submitted once, used for every customer you connect afterwards. This is the widest credential set of any Visma system connected today.
- One sandbox account per region you want to test
- The sandbox company is tied to its region at creation and each account holds one. A production client id reaches a sandbox company, but a sandbox client id never reaches a production one, so the two directions are not symmetric.
We walk through the registration and the callback change with you.
A Visma eAccounting listing reaches more markets than it names
Most providers stop at the API. Visma eAccounting runs a marketplace of its own, separate from the one Visma e-conomic runs, and reaching its audience is a process rather than a form.
Technical enablement
One integration against the Unified API and one data model, identical for Visma eAccounting and for everything else Maesn supports. Your engineers meet one interface rather than one per product.
Partnership support
Maesn initiates the listing for Visma eAccounting specifically and supports the co-marketing that comes with it. The listing carries your product's name rather than ours.
One listing, several markets
Because the same system is sold under different names across its markets, a listing here is in front of customers who call the product something else. That is an advantage this product has over the rest of the portfolio.
Not the e-conomic marketplace
The two products run separate marketplaces, so presence in one says nothing about the other. It is the same fragmentation the API side of this group has, appearing on the commercial side.
Co-marketing alongside it
The entry is the starting point rather than the whole benefit. What follows is joint visibility with the vendor, which is where a listing turns into pipeline rather than a directory row.
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 listing and support the co-marketing that comes with it.
