Please see attached startup guide & documents for Visma.net Integrations.
Following documents & Information will be useful when starting to the integration.
Currently, Visma.Net API does not support the "Password" grant type due to security policies.
Henceforth, all the new clients are registered only with "OAuth 2.0 Authorization Code Grant" flow.
After completing the testing phase, you should contact your partner service (How to contact), informing them with your Redirect_URI to obtain Live - Production Client
API Request Throttling configuration
Visma.Net Integrations - API Client Types
Here you can find the latest version of the start-up guide for Authorization_Code Flow.
1- Generating Token with OAuth 2.0 Authorization Flow
2- Code Example (C#) Generate Token with The Authorization Code Grant flow
Background Information on API Client & Token & Visma.net Financials User & Company
Visma.net ERP API uses OAuth 2.0 bearer tokens (OAuth 2.0 Authorization Code Grant) to authenticate API calls. This flow generate a token on behalf of the Visma.Net Financials user.
The authenticated user's access rights(Financials Administrator-Financials User) in Visma.net determine that the generated token can be used on which company. (The user to whom the token belongs needs to have the aforementioned roles in that company in order to access via the API.)
Supposing that there is X ISV has 2 customers and integration running like
1st Customer: a-b-c companies
2nd customer: d-e-f companies
-When token request made from the same API CLIENT ID:
Each company should have its own Visma.Net user to generate a token and this token will work as covering the companies based on the authenticated users granted roles on the Visma.Net Financials.
The token belongs to visma.net USER and can be used on any company where the user has "Financials User"-"Financials Administrator" role granted.
ISV should provide the interface for the client/user to interact with the web browser and each user should be authorized to generate a token by their own credentials.
If there are multiple companies, you should ask the user to select/specify which company is the integration made for.
This can be a one-time set up at the beginning then once you generate the token you can store it for that user and can be used on the companies which one the user has access to.
You can Get the companies available for the used token/Integration user via Context endpoint
for mapping user/token = Financials Company
Currently, Token Life Cycle does not have any specific interval, it's planned to facilitate as never expires. Each consecutively generated token automatically invalidates the recently created one.
(Request made from the Same CLIENT ID & the Same Visma.Net Financials user for all integrations/company) ❌
ISV / Integrator should ask their ERP Customer to have a different user for each integration/company. In this way, the integrator will use the same "client_Id" for all the integrations, but the ERP Customer will be using a different user for each company during the authorization. This is the recommended setup for our ISVs for obtaining a token while using the same ClientID for all the integrations. ✔️
In this way, If something goes wrong with one of the integrations (e.g. token gets invalidated), ISV generates a new token, then the other integrations will not be affected thus ISV can continue to use their existing token/s.
Copyright © 2022 Visma.com. All rights reserved.