Identity and access management
Loket to JumpCloud integration: JumpCloud users from all employers in Loket.nl
With an integration between Loket.nl and JumpCloud, JumpCloud imports every employee from Loket as a user, with employer, organisational unit and a status that follows from the employment. KoppelHet combines all employers into one list for JumpCloud's Custom API import, so a new employee is staged until their first working day and suspended after their last employment.
What the integration does
Organisations that have payroll processed in Loket.nl and manage devices and access in JumpCloud now create JumpCloud users based on an email or a list from the payroll bureau. Someone who is briefly out of service between two contracts is sometimes deleted and then returns without their laptop binding.
- A dedicated Loket user with read-only rights on your employers gives KoppelHet consent; JumpCloud gets its own token for KoppelHet's address.
- KoppelHet reads employees, employments and organisational units per employer and skips draft employees.
- KoppelHet puts all employees in one list, with employer, unit and the dates of the chain of employments.
- JumpCloud's scheduled import fetches the list and uses a state rule to decide whether the user is staged, active or suspended.
- IT binds user groups per employer or unit to applications and devices in JumpCloud.
What to watch for with Loket and JumpCloud
- Loket only grants access through a Loket user's consent, with a refresh token that is renewed continuously. JumpCloud's Custom API import does support OAuth, but not a refresh token. KoppelHet therefore keeps the connection with Loket and lets JumpCloud read its own address with its own token.
- In the Loket API employees sit under their employer, in pages per employer. JumpCloud wants one list endpoint with the full user schema. KoppelHet goes through all of the payroll bureau's employers that the integration may see and offers the whole with offset paging.
- An employment in Loket can be a chain of periods, with a gap in between. During such a gap KoppelHet delivers the status suspended, and with reactivation on update enabled in JumpCloud the user becomes active again at the next period, with the same device binding and groups.
- A staged user has no access to their applications in JumpCloud yet, and someone who was active once cannot go back to staged. KoppelHet only delivers employees who are no longer drafts, with the start date included, so the state rule only activates on the first working day.
- An employee number in Loket is only unique within one employer. KoppelHet puts the employer code in front of the number in employeeIdentifier, so JumpCloud does not treat employees of two employers at the same bureau as one user.
- In JumpCloud the work email and username are mandatory for every import. Loket usually only holds a private address for a new employee. KoppelHet creates the work address according to the naming rule with the employer's domain and leaves the private address out of the list.
- A scheduled import is off by default in JumpCloud and runs in a time zone you choose. We set the schedule to Dutch time and have KoppelHet refresh the list shortly before, so an end date in Loket leads to a suspension on the right day.
This integration is also part of joiner, mover, leaver.
How we build and run it
- The integration runs on the KoppelHet platform, hosted in a data centre in the EU.
- Every sync and every error is visible in the functional log; on an error your administrator is notified.
- A change that cannot go through is not half-applied but queued for another attempt.
- KoppelHet is ISO 27001 certified. Data travels encrypted and stays on the platform no longer than needed.
- After go-live we manage the integration and adjust it when your process changes.
- The integration fits next to your existing integration layer. Only the fields in the design are transferred; the platform keeps no register of its own.
Implementation and price
This is not an app you switch on. We build the integration for your organisation on our platform, with building blocks we reuse on every project. So it is custom work that does not start from scratch.
A consultant prepares the intake and analyses both systems. We then record the mapping and exceptions field by field, test in the test or acceptance environment and go live at a moment you choose. Costs are a one-off amount for the setup and a monthly amount for platform, monitoring and support.
Frequently asked questions
Can JumpCloud not read Loket itself?
Not durably: the import cannot renew Loket's refresh token. That is why KoppelHet puts its own address between the two.
Our payroll bureau manages several employers. Do we see all of them?
Only the employers on which the integration's Loket user has rights. When an employer is added, the bureau adds those rights.
Does JumpCloud delete a user after leaving?
No, the import suspends them. IT deletes them after the agreed period, so devices are collected first.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- Loket through the Loket REST API (oauth.loket.nl, authorization code and refresh token; no client credentials) under /v2/providers/employers/{employerId}/employees, with the employments as a chain of periods and the organisational units; paging with pageNumber and pageSize. Draft employees and pay or bank data are left out.
- JumpCloud: Custom API import (HR Directories) with Bearer Token on the KoppelHet address (refresh token and Basic not supported), GET method, offset paging, mandatory mapping Company email and Username, State through EXPR with manageUserState (STAGED, ACTIVATED, SUSPENDED) and date functions such as today() and dateAfter(), Allow reactivation of users on update, scheduled import with time zone (off by default).
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Loket | Field in JumpCloud | Notes |
|---|---|---|
Werkgevercode + employeeNumber | employeeIdentifier | Unique across all employers |
Naamgevingsregel met domein per werkgever | Company email en Username | |
firstName | firstname | |
prefix en lastName volgens naamgebruik | lastname | |
Werkgever | company | |
Organisatorische eenheid | department | |
Begin- en einddatum in de keten van dienstverbanden | State via manageUserState |
Related
ADP Workforce Now → Loket
ADP Workforce Now to Loket integration: hires, pay, hours and bonuses from ADP to the Dutch payroll run
AlexisHR → Loket
AlexisHR to Loket integration: employees of the Dutch company from AlexisHR into payroll
BambooHR → Loket
BambooHR to Loket integration: HR changes from BambooHR for Dutch payroll
Bullhorn → Loket
Bullhorn to Loket integration: placement as a concept employee in the right payroll administration