Identity and access management
Deel to JumpCloud integration: JumpCloud users for employees and contractors from Deel, with the Deel app or custom
With an integration between Deel and JumpCloud, everyone who works for you through Deel gets a JumpCloud user with job title, department, entity and worker type, and that user is suspended as soon as the departure in Deel is completed. Deel itself builds a JumpCloud app that creates, updates and suspends users; KoppelHet comes in for the manager, staging until the start date, new colleagues without a work email and a departure that still moves.
What the integration does
Organisations that hire people in several countries through Deel and use JumpCloud for devices and apps often switch on Deel's JumpCloud app. Afterwards they notice that someone without a work email does not arrive, that the manager is missing and that the username of a second colleague with the same name gets a number.
- Deel gets an organisation token with read rights only on people, contracts and organisation structure, and webhooks for direct employees and contracts.
- In JumpCloud the administrator creates a separate admin account with MFA and an API key on it for KoppelHet.
- For a new person in Deel KoppelHet creates a staged JumpCloud user, with a work email following your naming rule and the relation to the manager.
- On the start date KoppelHet activates the user, and groups per entity and worker type decide apps and devices.
- Once the termination in Deel is completed, KoppelHet suspends the user after the last working day.
What to watch for with Deel and JumpCloud
- The JumpCloud app is built and supported by Deel. On one page JumpCloud describes both a nightly and an hourly sync, and Deel speaks of changes within seconds. KoppelHet works on Deel's webhooks and records per person when JumpCloud was updated, so nobody has to guess which schedule applies.
- The Deel app skips anyone without a work email. For a direct employee the work email in Deel is an optional field at creation. KoppelHet creates the address with your naming rule and tells HR before the start date that it must be filled in in Deel, so the new colleague can sign in on day one.
- The Deel app builds the username as firstname.lastname and appends a number to the last name if that name already exists. KoppelHet checks the naming rule against JumpCloud beforehand and picks a fixed variant for a duplicate name, so the login name does not depend on the order of creation.
- The Deel app's field table has no manager, while JumpCloud knows the manager as a relation to another user. Deel passes a direct_manager for a direct employee. KoppelHet looks up the matching JumpCloud user and sets the relation, even if the manager is a contractor too.
- For an active person the Deel app sets the state staged or active, without the documentation saying which of the two. JumpCloud only knows staged at creation. KoppelHet always creates someone with status NOT_STARTED as staged and activates them on the start date.
- A termination in Deel goes through steps from PENDING to COMPLETED or CANCELED, and the last working day can still move during that time. KoppelHet only suspends after the last working day once the termination is completed, and does nothing on a cancelled termination.
- The webhook for an updated direct employee gives the current state, but not which fields changed. KoppelHet compares with the previous state and only sends changed fields to JumpCloud, so an adjustment IT made to another field in JumpCloud stays in place.
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
Do contractors also reach JumpCloud?
Yes, if you want that. The worker type goes along as employeeType, so contractors can get different groups and devices.
Why not just Deel's JumpCloud app?
It is often enough if everyone has a work email on time and JumpCloud needs no manager. Choose custom work when staging and departure must be right to the day.
Does salary data go to JumpCloud?
No. KoppelHet's token has no rights on compensation or payments.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- Standard: Deel's JumpCloud app (Deel App Store, Built by Deel) with a JumpCloud API key from an administrator (Manager, Administrator or Admin with Billing); Org Admin rights in Deel. Fields: work email, first name, last name, full name, job title, department, work location, team to costCenter, worker type, entity and profile ID. Manual sync in Deel under Apps & Integration.
- KoppelHet reads Deel through the REST API (version 2026-01-01; GET /rest/people with hiring_type, person_status, client_legal_entity, department, direct_manager, employments, active_worker_termination_status and direct_employee_termination_last_day) and webhooks, including Employee Created Direct and Employee Updated Direct for direct employees. Own employees following the Deel guide as direct employees under the own legal entity.
- To JumpCloud through API v1 /systemusers (header x-api-key): employeeIdentifier unique per user, employeeType, company, manager as a relation, state STAGED only on creation, then ACTIVATED or SUSPENDED.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Deel | Field in JumpCloud | Notes |
|---|---|---|
Deel-id van de persoon | employeeIdentifier | |
first_name en last_name | firstname en lastname | |
work_email of naamgevingsregel | email en username | |
job_title | jobTitle | |
department | department | |
legal_entity | company | |
hiring_type | employeeType | |
direct_manager | manager | JumpCloud ID of the manager |
start_date en laatste werkdag | state (STAGED, ACTIVATED, SUSPENDED) |
Related
Ashby → Deel
Ashby to Deel integration: hires at the own entity as direct employee in Deel
Bullhorn → Deel
Bullhorn to Deel integration: first placement as a direct employee with a contract in Deel
Carerix → Deel
Carerix to Deel integration: successful placement as a person or contract in Deel
Deel → 4PS Construct
Deel to 4PS Construct integration: own employees of the construction entity in 4PS, with department and cost centre as dimensions