Hello, this has been reported as an error, and it is currently under review by the team.  ... Skatīt vairāk

Hi, we'll check it out.  ... Skatīt vairāk

The solution was provided above, and it was just an issue with how swagger prints out examples.   If it isn't too breaking of a change. Since subaccount can contain a varying amount of segments, wouldn't it make more sense that it was a list instead? Something like: [ { "id": "string", "value": "string" }, { "id": "string", "value": "string" } ]   ... Skatīt vairāk

Hi! We'll will check this internally. If I'm not mistaken, the applications under your applications are the applications where you have a role assigned, so most likely your own and your teams, but we'll doublecheck this as well. Thank you.  ... Skatīt vairāk

The fix has been released in Visma.Net API 9.08.0 ... Skatīt vairāk

I still get this error almost every day.     ... Skatīt vairāk

You are right. I get the customer mismatch error in the UI when entering the project number.   It is wrong there as well of course so the problem is not in the api. ... Skatīt vairāk

Ah, I missed that extra indirection. Thank you for a quick response. ... Skatīt vairāk

Thanks for coming back.   Just curious why you don't consider renaming every type in the API a breaking change or even worth mentioning in the release notes?   But I assume it is interesting to know that I am the only one in the community using auto-generated code. ... Skatīt vairāk

According to the specification, refresh_token is optional. A client requiring it is non conforming. Extra fields are indirectly allowed "typically along with some additional properties about the authorization."   So having both "token" and "access_token" is fine according to the standard but I assume Hyrum's law applies as well.       ... Skatīt vairāk

I see it in the same way as stored procedures vs queries when dealing with database access.   There are cases where it is ok to expose your internal data structure. Adding an extra layer can then be an unnecessary maintenance burden. GraphQL and similar interfaces will play a role in places where you control the entire chain from data- to presentation layer.   But I don't think it is a good fit for general API:s where you give 3rd parties access to your functionality. It puts to much burden on the consumers for understanding your data model. If you have ever had to use an OData interface into someone else's system you know what I mean 🙂   You can of course create a GraphQL API which is independent from your data model but then I'm not sure what you really gain compared to REST.   (Disclaimer: I create REST interfaces at least every month and the design goal is always to expose an API which makes sense for the consumer independent of the data layout. Have also created OData interfaces in the past and found that it worked best for reporting and other data extraction scenarios. Many BI tools can read OData out of the box and I assume it is the same for GraphQL) ... Skatīt vairāk

This is the information that we received from the infrastructure team about how that specific exception is built. If there are inconsistencies in the scenarios of when the exception thrown, please inform us on the followed steps before you've received the response so that we can check this out in detail. ... Skatīt vairāk

Last reported connection problem was at 9:12 so it is resolved. ... Skatīt vairāk