Quota on API

[Florian Haase]

Hi

are there any plans about quota in the API or is already something about that?

Florian

[Florian Haase]

After mailing with Alexandra I try to follow up this thread again:

- Is there any documentation in the meanwhile?

- We are working on a quite big customer with startup on the 1st of september. Here are really a lot of integrations running and there will be thousand of API-calls in a short time. Have you any idea how we can handle that we don't stop the customer at once when we hit the quota and how we can avoid stop in the production system in a longer time when we have to optimize our systems. Here we need to help each other to avoid a bad experience for the customer. We could also show you what we are working on and what the scope of the project will be.

- we did hit the quota on Monday - due to a bad handled programcode - but that stopped a lot of extensions here. I think we could from our site setup the client-id for each integration-thread, but that will cause to give access to many client-Ids in the user setup at the customer. Maybe we can see what your suggestion about this would be.   

Florian

[Arnstein By]

We do have rate limiting in place and will soon publish documentation on this, together with timeout- and message size limits.

For rate limiting, we allow 15 requests per second per client, with occasional bursts up to 25 per second.

Unfortunately, currently error 503 (System Unavailable) is returned when rate limiting is triggered and not 429 (Too Many Requests), which is the standard. We will correct this and also add the Retry-After <delay-seconds> in the response header.

[Florian Haase]

Thank you for your info. I think this can get a bit trouble especially when one customer behavior affects the other customer because they are running on the same client-ID. And I guess that was not the meaning from Visma to create client-IDs per customer?

[Marius Bancila]

I am not familiar with the problems you are having. If you discussed something with support then please follow up. Otherwise, you'll have to provide the details here so that I know that you're talking about.

[omelhus]

What Florian is really asking is that you provide some documentation around rate limiting and what you consider best practice for working within the limits.

I think all of us consultants will appreciate it if you could shine a light on how rate limiting is implemented and enforced.

[Florian Haase]

At least when we tried on Friday with a bit of bad optimized code it was enforced in that way:

HttpRequestException: Klarer ikke å sende data! Response status code does not indicate success: 401 (Unauthorized).

I used the night from Monday to Tuesday to delete about 400.000 loglines with that message 🙂

We optimized our code and it was working again after that but in the meanwhile it stopped all calls from this client-id. 

Florian

[Marius Bancila]

No, the rate-limiting is not yet documented.

Your feedback is important for helping us build the features you need so that's why I asked for elaborating on what you guys need/want.

[omelhus]

Alright, I want to build business-to-business e-commerce solutions fetching product groups, products, prices, customers directly from VB NXT. We have this with Zpider and VB on-premise today, and it would be great if we could do the same with VB NXT, but in a Cloud fashion.

This is also why it's important that the process to fetch prices is fast. 

[Marius Bancila]

Yes, we currently have a rate-limiting per user/service per second.

However, we do not have a mechanism for quota limit plans that allows you to buy some quota range.

Please elaborate on what you are actually looking for.

[omelhus]

Do you have the rate limiting documented anywhere? There's no headers advising on rate limiting.

If you get the processing for customer product pricing there will be a business case for quota limit plans.