Status page has been updated. We should be fully operational without hiccups for the API. https://status.visma.com/incidents/9z0fvnd1x177 - It would be nice to get some feedback from the ISV's side. Sorry for the inconvenience. ... View more

We are aware of the challenges and troubleshooting the issue. Follow the status here: https://status.visma.com/incidents/9z0fvnd1x177 ... View more

We are closely monitoring and stabilizing the environment. There was a config change which took effect between 0859 and 0913. ... View more

Thank you for the feedback. It still not 100% and we are looking into it. Please follow the update here: https://status.visma.com/incidents/xv1m8gn8nc5r ... View more

It was a temporary glitch. Up and running again from 0757. Can you guys confirm? ... View more

Hello. This also affects the API: https://status.visma.com/incidents/m72jjnbt3qjp We are investigating the problem. ... View more

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

You can find the swagger documentation here: https://integration.visma.net/API-index/ ... View more

Hello.   We have done some major performance improvements on GET InventoryTransfer endpoint in Tuesdays version. https://community.visma.com/t5/News-in-Developers-Visma-net/Release-Notes-Visma-Net-API-9-50-0-06-06-2023/ba-p/584582 It should fetch bigger datasets much faster. Please provide feedback on the improvements. ... View more

Hello.   You now have the possibility to filter on warehouse on the inventorytransfer endpoint: Release notes 9.41  This should help on getting more in-point data in your use case. We are also working on improving this endpoint on a general level and the improvement will come in a couple of weeks. ... 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

We are on it: https://status.visma.com/incidents/gh9ndhwrmqw5 ... 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

Just double checking, you are using the overridenumberseries on v2 of customerinvoice right? From release notes: Override number series for POST CustomerInvoice V2 You are now able to override the number series of a customer invoice by specifying the field overrideNumberSeries=true when creating a customer invoice. This functionality has to be enabled in the Number series (CS201010) window by selecting option Allow manual numbering on imports. You also can specify a longer customer invoice number when using overrideNumberSeries than what is specified in number series for customer invoice. This option is only available for V2 of the customer invoice endpoint.   ... View more