Paging in the Employee API not working as expected

[RIchard Larre]

Hi,

When utilizing the endpoint

https://employeeapi.employeecore.hrm.visma.net/v1/employees?page-size=10

my expectation was to receive a response containing a list of 10 employees along with a nextCursor parameter for querying the subsequent set of 10 employees.

I have both tested this functionality in my code and examined the Swagger documentation.

However, instead of receiving the expected 10 employees, I am getting responses containing all registered employees.

This discrepancy is causing concern, particularly regarding how the API will perform when handling clients with more than 200 employees, which is the maximum limit specified in the documentation for this request. Unfortunately, I lack access to a client with a sufficiently large number of employees to conduct thorough testing in this regard.

Regards,

Richard Larre, ECIT Capstone

[RIchard Larre · Accepted solution]

The paging is a functionality that has to be activated by Visma per application per tenant.

[RIchard Larre]

Testing the paging in a client by creating 200+ employees is of course not a problem.

I have mainly two concerns regarding the Employee/Payroll API.

Firstly, despite the documentation's description, it seems that the paging mechanism does not operate as expected. I find it strange if the paging should suddenly work if there are more than 200 employees. This deviation from common practice is concerning, particularly given its impact on integration efforts. Understanding the underlying behavior of the API paging feature is crucial for efficient system operation. 

Furthermore, the lack of response from Visma in this forum the last two years is very concerning. As our organization encounters an increasing number of integration cases involving Payroll and Employee, response and assitance from Visma would be greatly appreciated in the future.

Regards,

Richard Larre, ECIT Capstone

[Glen Nordskog_Exsitec]

I share that concern.

Haven't used the EmployeeAPI on  a client with >200 employees yet, but discovered the paging discrepancy while writing and testing paging helpers in our employee library.

I suppose we could find out what happens in the >200 employees case by creating a sufficient number of draft employees.