Rate Limits

Overview

Visma Net API uses rate limits to maintain system stability and ensure high performance for all our users.

In the past, these limits were listed as static articles in the Developer Forum. To make things easier and more accurate, we now provide this information dynamically. You can find your current status directly in the response headers of every API request.

Current Rate Limit Policies

We currently have two policies in place to manage traffic effectively:

• Policy 4-fixed-window (Standard): X requests per Y hour per company/client combination.

• Policy 6-fixed-window (Migration): This is a specific limit for calls to the old integration.visma.net. Read more about this migration here: End of life notices: Change Base URL

How to Monitor Your Limits

The API includes specific headers in every response that show your current usage. These headers are for informational purposes and help you track your limits in real-time.

The four headers are:

• X-RateLimit-Limit: This shows the total number of calls allowed for the specific company and client within a time window.

• X-RateLimit-Remaining: This tells you exactly how many requests you have left before you reach the limit.

• X-RateLimit-Reset: This shows how many seconds remain until the window resets and you get a fresh balance of requests.

• X-RateLimit-Policy: This shows the name of the policy being applied (for example, 4-fixed-window).

Handling Throttling

Your requests are only being limited if you receive a response with status code 429.

When you receive a 429 response, the API will also include a Retry-After header. This header indicates the exact number of seconds you must wait before a retry will work.

This header can be used to build a retry mechanism.

Best Practice

To ensure your integration runs smoothly, we recommend that you:

• Monitor remaining requests: Use the X-RateLimit-Remaining header to keep track of your balance.

• Handle 429 errors: At a minimum, your code should be able to detect a 429 status code and wait for the time specified in the Retry-After header.

By using these headers, you can create a more proactive integration that avoids interruptions and provides a better experience for the user.