Identity and access management
Deel to OneLogin integration: employees, EOR and contractors from Deel as OneLogin users with roles
With an integration between Deel and OneLogin, everyone who works for you through Deel becomes a OneLogin user, with roles per entity and type of work relationship and with the manager, and that user is suspended after the last working day. Deel sends nothing to OneLogin itself; KoppelHet is the middle layer Deel prescribes for this.
What the integration does
Organisations that have OneLogin as their identity provider and hire people through Deel often look for a Deel directory or app in OneLogin and do not find one. New colleagues are then created by hand, and contractors and EOR employees keep access until someone remembers to suspend them.
- Deel gets an organisation token with read rights only on people, contracts and organisation structure.
- In OneLogin the administrator creates an API credential with Manage Users and the roles per entity and type of work relationship, plus the custom fields KoppelHet fills.
- For a new person KoppelHet creates the OneLogin user, suspended until the start date, with roles and manager.
- On the start date KoppelHet sets the user to active, and OneLogin grants access to the apps through the roles.
- After a completed termination KoppelHet suspends the user; deletion only happens after the retention period.
What to watch for with Deel and OneLogin
- In its own guide Deel writes that it does not provision to identity providers itself and that the same middleware approach also applies to OneLogin. OneLogin has no directory for Deel. KoppelHet reads Deel and writes through OneLogin's user API, so no second identity provider is needed in between.
- OneLogin requires at least a username and an email address at creation. For a direct employee the work email in Deel is optional. KoppelHet only creates the user once there is a work email, or creates one with your naming rule, and tells HR it must go into Deel too.
- In OneLogin roles decide which apps someone gets. Deel has direct employees, EOR employees and contractors, each at an entity. KoppelHet translates the combination of entity and type of work relationship into role_ids, so a contractor in Germany gets different apps from a direct employee in the Netherlands.
- A custom field that does not exist in OneLogin causes an error at the API instead of being ignored. At the start KoppelHet checks which custom fields, such as type of work relationship, have been created in OneLogin, so a new person does not get stuck on a missing field.
- The webhook for an updated direct employee gives the current state without a list of changed fields. KoppelHet compares with the previous state and sends an update to OneLogin with mappings that run straight away, so a new department immediately produces the right apps too.
- Deel advises deactivating users in the identity provider rather than deleting them, for the audit trail and for rehires. KoppelHet sets a leaver in OneLogin to suspended and only deletes after the retention period, so a contractor who returns gets their user back with the same external_id.
- Deel gives the manager as a reference to another person in Deel, OneLogin wants the OneLogin ID in manager_user_id. Because the Deel ID is the external_id on every user, KoppelHet finds the manager with a single lookup, even if they work in another country.
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 get different apps from employees?
Yes, if your roles are set up that way. KoppelHet gives every type of work relationship per entity its own role.
Does salary or payment data go to OneLogin?
No. The 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.
- 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. Own employees following the Deel guide as direct employees under the own legal entity. With too many requests Deel responds with 429.
- To OneLogin through API v2 with the Manage Users scope: POST and PUT /api/2/users with username, email, external_id, title, department, company, manager_user_id, role_ids, custom_attributes and status (1 active, 2 suspended), with mappings=sync. Username unique per subdomain; unknown custom field returns 400; no invitation email through the API.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Deel | Field in OneLogin | Notes |
|---|---|---|
Deel-id van de persoon | external_id | |
first_name en last_name | firstname en lastname | |
work_email | email en username | |
job_title | title | |
department | department | |
client_legal_entity | company en role_ids | |
hiring_type | role_ids en custom attribute soort arbeidsrelatie | |
direct_manager | manager_user_id | |
person_status en beëindiging | status (1 actief, 2 geschorst) |
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