to get a personalized navigation.
to get a personalized navigation.
Throughout the years, our Visma Net Integration (VNI as some say) has been used by you to solve many business problems customers have encountered. We are announcing the end of VNI, effective April 30th, 2025. We would like all clients who are still using our Visma NET API to follow the technical changes noted at the bottom of this article.
These changes are necessary to improve the overall experience by using our ecosystem. This change will naturally enhance the performance and increase the capabilities of our API. Migrating is an important step to keep your integrations and our customers' business cases a step ahead.
Once migrated, you should experience improved API performance, which will translate into faster operations, greater reliability, and the ability to implement more complex business solutions. By adopting the updated API base URL, customers ensure their integrations remain compatible with Visma's ecosystem and leverage ongoing enhancements.
In most cases, this change should be relatively straightforward to implement. However, for more complex integrations, the process may require additional time and thorough testing to ensure everything functions as expected.
Contact your vendor of the integration or Partner to clarify the necessary steps that need to be taken for your instance.
Contact details for technical support: cloud.api.support@visma.com
We will also arrange a webinar if there is enough interest in this topic. Fill out this form to sign up for the webinar.
There are breaking changes when moving to the new base URL. These changes require updates to your existing code and configuration.
Example: GET https://api.finance.visma.net/v1/account (Note the lack of “api/”). Make sure code is not denying https://api.finance.visma.net as a base url, in case you have code that “follows” a location header on a response. When changing to API Management we will change the base URL. In the first period we will have support for the current URL. We want all integrations to start using the new base URL.
The new API Management has a 4-minute timeout restriction. This means that API requests taking more than 4 minutes will respond with a web timeout error. To circumvent such situations, all API requests that spend more than 4 minutes can be refactored into being “background-api” calls. If you are not sure what “background-api” calls are please check out this link.
Add a webhook subscription in Developer Portal for the event. With the value “none” in the header, there will be no notification when the call is done executing. With the value “subscription”, a webhook notification will be sent to the webhook subscriber that is set up in Developer Portal for the “Visma net” application event named “BACKGROUND_API_RESPONSE”. The <custom-headers> part is optional. It supports name/value pairs in the format <headername_1>=<value_1>,..,<headername_n>=<value_n>. When specified, the keys will end up as custom headers in the webhook notification with the corresponding values. Here you can typically specify your own reference ids to be able to recognize custom state for the
BACKGROUND_API_RESPONSE from application Visma net (vismanetfinancials). The webhook listener is triggered when a response is ready from the background job and code here can check the result and fetch the actual response payload, if any, and process it as desired. The code logic regarding this response should normally be put in this webhook listener.
To the request, add the header erp_api_background with the value “subscription” (without quotes and with any optional custom headers for the webhook request).
Alternatively, if you cannot change the architecture to add an http listener for webhook notifications, you may call the api with the erp-api-background header value “none” to still utilize an asynchronous api call to queue a task and get an immediate response, but not trigger a webhook when work is finalized. If your client needs the “real” result before moving on, you can request GET ..v1/background/{id} to poll if work is done or not, and if done, you may GET ..v1/background/{id}/content to get any response payload for the finished task.
All webhook events of type data-changed and action-triggered) will be automatically migrated to the new system in Developer Portal as they are currently handled in VNI. All future creation, updates and deletion of webhook subscriptions must happen in Developer Portal.
If you already have an application in Developer Portal, the subscriptions will appear there under the appropriate application (client). For integration clients that are not in Developer Portal, the webhook subscriptions will be placed under a common “VNI webhook migration” application. To maintain these later, contact with our support is necessary.
After the migration of webhook subscriptions from VNI is done, its resources/event and resources/subscription api endpoints to list events and create or maintain webhook subscriptions, will not work anymore.
If you today pass any values as part of the url path, like querystring arguments, these must be refactored into custom webhook headers using the following format for the erp-api-background header:
subscription[:<headername_1>=<value_1>,..,<headername_n>=<value_n>]
These name/value pairs will come as headers on the Webhook request and the webhook listener must be refactored to read the values from the headers instead of the URL.
Our (new) Visma Webhook Dispatcher service will after 30.04.2025 be the sender of webhook requests. If you have any white-listing configuration, this must be changed to allow this new sender’s IP addresses (18.202.121.26, 34.242.104.102, 54.220.26.45)
Copyright © 2022 Visma.com. All rights reserved.