Leave, absence and time
Deel to Protime integration: employees from Deel in Protime, approved absence back as time off in Deel
With an integration between Deel and Protime, every employee of an entity that clocks in Protime appears in Protime automatically, with start date, department and a contract. Absence approved in Protime goes back to Deel as approved time off, so the balance and leave calendar in Deel are correct without a second approval.
What the integration does
Organisations that manage employees in Deel and clock with Protime in the Netherlands or Belgium enter every new colleague into Protime by hand. Leave goes through Protime's terminal or app, but does not reach Deel, so the leave balance in Deel is wrong and HR updates it by hand.
- HR creates an employee in Deel at an entity that works with Protime.
- KoppelHet puts the person in Protime, with a contract and the department and work location from the start date.
- The employee requests leave in Protime and the manager approves it.
- KoppelHet first validates the request with Deel and then enters it as approved time off in Deel.
- If the absence is changed or removed in Protime, KoppelHet updates or cancels the time off in Deel.
Back: Approved absence as time off, with half days or hours per day
What to watch for with Deel and Protime
- Protime offers no write access to absence, while Deel accepts time off through the API and sets it to approved by default. Leave is therefore requested and reviewed in Protime; Deel receives the result. KoppelHet leaves Deel's approval flow switched off, so the manager is not asked again.
- Deel recommends validating a request first against balance, leave policy and required custom fields. KoppelHet runs that check before booking. If Deel rejects the request, HR gets an alert with the reason, instead of a retry that keeps returning the same error.
- Deel can split one request into several time offs on creation, depending on the dates. KoppelHet keeps all IDs Deel returns with the absence from Protime, so a later change or deletion affects every part.
- Within one request in Deel all days must have the same kind, such as full day, half day or hours. Protime reports a day part and a duration per day. If a half day sits in the middle of a series of full days, KoppelHet turns it into separate requests, so Deel does not reject a request with mixed days.
- If the manager moves an approved day off in Protime, KoppelHet corrects the dates of the existing time off in Deel. If the absence disappears in Protime, KoppelHet cancels the time off; Deel then sets it to cancelled at once, even if it was already approved, and that cannot be undone.
- Deel has a separate endpoint through which an external HR system syncs time off, but only for Global Payroll contracts. If payroll for the Dutch or Belgian employees runs outside Deel, KoppelHet uses the regular time off request per employee.
- Protime wants the contract hours and the hours of a full-time week on a contract, while Deel delivers no hours in the people API. KoppelHet reads both from custom fields in Deel, or from a table per entity, and reports an employee without hours before Protime is left with a person without a contract.
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
Why request leave in Protime and not in Deel?
Because Protime does not accept absence through the API. Whoever arranges leave at the clock does so in Protime; Deel receives the result and keeps the balance.
Do EOR employees go to Protime too?
Only if they clock at a location with Protime. We choose per hiring type and entity who is included.
Do clocked hours go to Deel?
Not in this integration. Clocked hours for payroll can be added later as an extension.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- Deel through the REST API (version 2026-01-01) with an API token or OAuth2 app. Employees through GET /rest/people and webhooks for created and updated direct employees; custom fields through the custom fields API. Absence back with POST /rest/time_offs/validate and POST /rest/time_offs (recipient_profile_id, time_off_type_id or policy_id, start_date, end_date, dates with day_type HALF_DAY, FULL_DAY, PERCENTAGE or HOURLY, status APPROVED, use_deel_approval_flow false), PATCH /rest/time_offs/{time_off_id} for corrections and DELETE to cancel. Scopes time-off:write and worker:write.
- Protime through the Protime API (v1) with OAuth 2.0 client credentials. POST people with externalReferenceIdentifier, POST contracts (contractHoursInMinutes and fullTimeEquivalentInMinutes between 1 and 5999) and the history for employer, department and work-location. Absence is read through webhooks on absences (dayPart First or Second, durationInMinutes, approvalLevel Approved), signed with HMAC-SHA256; absences have no write scope.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Deel | Field in Protime | Notes |
|---|---|---|
employments[].employee_number | employeeNumber en externalReferenceIdentifier | Fixed key |
first_name, last_name | firstName, lastName | |
employments[].start_date en termination_last_day | inServiceDate en outOfServiceDate | |
Eigen veld contracturen | contractHoursInMinutes | Deel has no standard field for hours |
client_legal_entity | employer-history | |
department | department-history | |
work_location | work-location-history | |
Afwezigheidsdefinitie, dayPart en duur (Protime, terug) | time_off_type_id, dates[].day_type en hours | Through a table per absence code |
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