The problem is reproducible by creating a new Visma.net database using Visma Connect (not the obsolete VNI):
select *
from Customers
Example request ID:
0HNDEDH6Q8TVJ:00000007
HTTP-error: 404
The location https://integration.visma.net/API-index/doc/swagger
for Swagger raises an error:
<Error>
<Message>An error has occurred.</Message>
<ExceptionMessage>Unknown API version - vi</ExceptionMessage>
<ExceptionType>Swashbuckle.Swagger.UnknownApiVersion</ExceptionType>
<StackTrace> at Swashbuckle.Swagger.SwaggerGenerator.GetSwagger(String rootUrl, String apiVersion) at Visma.net.ERP.Web.Api.SwaggerProvider.GetSwagger(String rootUrl, String apiVersion) in D:\Data\BuildAgent\work\29e70b1f9d289120\src\Lib\Visma.net.ERP.Web.Api\SwaggerDocumentAccessor.cs:line 54 at Swashbuckle.Application.SwaggerDocsHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)</StackTrace>
</Error>
A Swagger-definition can be found on:
https://integration.visma.net/API-index/api/vismanet.erp.service.api-apim
The problem occurs since 19-06-2025 09:27:46 UTC. It does not occur for all API-calls, only approximately 32% of page number 1 retrievals is affected.
Failure Depends on URL Used
API-calls failing seem all to use the following prefix to address Visma.net API servers:
https://integration.visma.net/API/api/...
whereas successful API-calls for the same data set are all using the prefix:
https://integration.visma.net/API/controller/api/...
The use of different URLs happens within the same version of Invantive Bridge Online 24.0.727.
Users Start to Fail Dynamically
One specific user seems to have switched from using the API URL with /controller
to the non-working without between 01:34:23 UTC and 04:15:23 UTC. The first failing request ID is 0HNDEDHA244CK:00000003
.
The associated user updated the EDM data model cache on June 18 already. However, the metadata specification provided by Visma changed for this user at 04:15:
Date |
Size (bytes) |
Version in Specification |
Basepath |
20250620 |
2588397 |
v1 |
/1053011001/ |
20250618 |
2599271 |
10.53.01.1001 |
/API |
20250611 |
2599016 |
10.52.01.1002 |
/API |
It seems that Visma has significantly changed the metadata specification on June 19 before 09:28 UTC. All use of the new metadata specification causes a failure, when a user’s cache is being updated to use the new metadata.
The new metadata specification no longer contains the URL path /controller
besides in some (historical?) comments such as:
This property replaced by an action, please use the following sub-endpoint:/controller/api/v1/PurchaseReceipt
The basepath has also changed, which is currently hardcoded in the Visma.net SQL-driver as /API
.
Problem may be related due to the switch of Visma.net on June 19 at 10:50 CET (08:50 UTC) to the new API proxy of all API traffic.