Pro tip for ISVs: Subscribe to webhook notification from status.visma.com so that you can automate your integration. Here is how to do it: https://community.visma.com/t5/Knowledge-base-in-Developers/How-to-subscribe-to-the-Webhook-notifications-for-Visma-Cloud/ta-p/346725 ... View more

Hello. Sorry for the late reply. 1) As mentioned earlier by Roy, we are working on improving our endpoints, so they can respond faster and deliver more specific information instead of everything as of now. One example of this work is the neXtGen SalesOrderService which includes v3/salesorder, v3/inventory and v3/customer More info about it can be found here: Getting started with the first neXtGen service: Visma.net ERP Sales Order API    2) As you are mentioning, we are running in a multi tenant environment with shared resources, and we have to have in place some measurements to ensure the quality of the service. That is the reasoning behind having a concurrency policy. We have not landed on a number yet, but it will most likely be a percentage of the resources available in the environment. ... View more

This throttling or rate-limiting policy will reject the next request and give it a 429 response if there are already X_number_of_requests in progress from the client on a company.   The response will contain the header "x-rate-limit-policy: ConcurrentRequestsLimitPolicy” to tell the client which exact policy was violated. The server will not send a retry-after or similar header, since the server will not know how long it takes before the current requests are finished executing.    This is why the client itself needs to keep track of its requests. The client should have a counter for concurrent requests. It needs to be increased on every new request sent and decreased on every response received.  The counter should be in "shared" storage if the client exists as several instances. This way, the client will know if it is allowed to issue the next request; when counter < X_number_of_requests.   We are still gathering data to best determine how many concurrent calls we should be allowed. The X_number_of_requests variable will be clearly communicated beforehand.   We do not support queueing requests, other than what is standard for web servers. Neither will we implement it for the normal flow, where the purpose is a request/response pattern. Such queueing of requests would soon result in timeout errors on the clients, since they would have to wait for the responses.    However, we are working on a way to call the APIs with a special header to indicate that the entire request will be persisted in a storage or queue and will respond immediately with 202-Accepted, while the actual invocation is done as a background task. There will be a webhook notification when a response is available.  This approach is suitable for clients that do not need to wait for a response in order to continue its flow, or for clients that need to carry out an operation via the API that will take a while. This work is in progress and is expected to be delivered in Q1/22. ... View more

Was anyone able to try this out? Feedback? ... View more

@Trygve Storrønningen1  Thank you for your feedback. We will add current version(8.25.49.1020 ), next version (8.26.x) and the time when the maintenance will be completed in the message. Stay tuned. ... View more