Itgenoda042 OData URL Visma.net not available

Questions
1

I am getting this error since today. Visma status website says API is online, so don’t know where this is getting stuck.

image
image1614×809 92.9 KB

Error:

itgenoda042
De gevraagde OData-URL is niet gevonden op de Visma.net Financials-server.
Gelieve contact op te nemen met Invantive Support of gebruik een andere tabel.

Query:

select *
from   VismaNet.Branch.Branches

Natural key such as:

https://integration.visma.net/API/api/v1/customer?pageNumber=1&lastModifiedDateTimeCondition=%3E%3D&pageSize=100&lastModifiedDateTime=2025-06-12T00%3A00%3A00
2

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.

3

The new API proxy of Visma has changed the metadata structure of the Visma.net API considerably.

It is yet unclear whether this concerns solely an upgrade from one metadata specification format to another, or that also APIs have changed. It is expected however that it is only a version change, which needs to be incorporated in the Invantive software when possible.

The Visma.net SQL-driver will be unavailable until this issue has been analysed and resolved.

4

Do you have an estimate of when I can expect an update? Would like to know if I need to research an alternative if this is not fixed on time.

5

There is no estimate. At the end of Monday June 23 this topic will be updated with the then current status of the analysis and actions.

1 like
6

Visma has made available a quick fix on production on June 20 for the metadata specifications, which were broken on June 19.

The fixed metadata specifications signal that Visma.net API servers have obsoleted the Code Grant Flow, and only the Client Credentials flow is still supported.

We have reached out to Visma.net Support whether this is an intended (breaking) change.

7

An improved version has enterd test phase.

Questions remain on a number of issues, but it is uncertain whether the answers once found will influence the test.

8

The tests sofar have indicated that a new release can be built for further integration testing.

Excluded from integration testing is verification that all tables and columns have identical contents and naming. This is in line with the policy to work on basis of a 1:1 mapping between APIs and table contents. Once released into production, please remember to verify your reports.

The release is scheduled for live as described in:

For completeness, an overview of Invantive’s policy for breaking changes by platforms and the motivations has been published on:

9

Release 24.0.738 with fixes has been taken into production on Invantive Cloud.

In case the database raises an error during opening, please refresh the authorization as described in: