Absence reporting (SIVI)
Keka to the occupational health service via SIVI: sickness leave requests as absence reports
With an integration between Keka and the occupational health service, an approved sickness leave request of a Dutch employee in Keka automatically becomes a sick or recovery report at the health service, in the SIVI format. Even if a request is partly sickness and partly another leave type, only the sickness part goes to the health service.
What the integration does
Organisations that use Keka for HR and leave, with a team or office in the Netherlands, need a health service for those employees. Sickness is then a leave request in Keka, and HR copies every sickness report by hand to the health service portal.
- At the start we pick the leave types in Keka that are sickness and which employees fall under the Dutch employer.
- For a new request Keka sends a webhook; KoppelHet then fetches the request itself through the API.
- After approval the sickness part of the request goes to the health service as a sickness report.
- Every hour KoppelHet looks at requests with a new action, such as a cancellation or a changed end date.
- After the last day of sickness the recovery report follows. A cancelled request that was already reported becomes a task for HR.
What to watch for with Keka and Arbodienst (SIVI)
- A leave request in Keka can be split across more than one leave type, with a number of days per type. If a request is partly sickness and partly holiday, KoppelHet only takes the days of the sickness type. The holiday days stay in Keka.
- Keka returns leave requests for a period of at most ninety days, and without dates only the last thirty. KoppelHet requests a fixed period each run and uses the time of the last action on a request to see what changed since the previous run.
- The webhook Keka sends for a new request contains dates as readable text, such as 24 Oct, 2024, and a note from the employee, but no request ID. KoppelHet only uses the webhook as a signal and fetches the request through the API; KoppelHet does not store the note.
- Keka records for the first and last day whether it is the first or second half of the day. Someone who goes home sick in the second half of the day gets that day as the first day of absence at fifty percent at the health service.
- The status of a request is a number in the API without a description in the documentation. At the start we test with a requested, approved, rejected and cancelled request which number means what, so that only approved sickness goes to the health service.
- Keka's API documentation has no field for the Dutch safety net scheme, while SIVI requires that data. KoppelHet reads the safety net from a custom field on the employee. The reason for cancellation or rejection also stays out of the message to the health service.
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
What if an employee puts sickness and holiday in one request?
Then only the sick days go to the health service. Keka keeps track per request of which part belongs to which leave type.
Is the note on the request sent along?
No. The health service gets dates, a percentage and codes. Notes and reasons stay in Keka.
Does this work for employees outside the Netherlands?
No. Only employees of the Dutch employer go to the health service. Sickness of colleagues in India stays in Keka.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- Keka through the REST API with OAuth 2.0 (scope kekaapi), at most two hundred results per page. GET /time/leaverequests with from and to (at most 90 days, default the last 30) and employeeIds; fields id, employeeIdentifier, employeeNumber, fromDate, toDate, fromSession, toSession, status (number), selection (leaveTypeIdentifier, leaveTypeName, count, duration) and lastActionTakenOn. GET /time/leavetypes for the sickness types. Webhook leaverequestcreated through Settings > Communications > Event Triggers.
- The SIVI messages Employments, Employee data and Absence reports go to the health service, with processing code new, changed or correction, Vangnet J/N (mandatory) and a cause code without diagnosis. Transport under the SIVI 2025 interface specification (REST endpoint at the health service, XML in Base64 inside JSON, OAuth 2.0), with a return and processing message back.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Keka | Field in Arbodienst (SIVI) | Notes |
|---|---|---|
employeeNumber | Identificatie werknemer | No citizen service number |
employeeIdentifier | Identificatie dienstverband | |
Leave request id | Verzuimgeval identificatie | |
fromDate en fromSession | Datum eerste verzuimdag | |
selection met ziektetype (count) | Percentage verzuim | Half days become fifty percent |
toDate + 1 dag | Datum hersteld en Einde verzuim J/N | |
Eigen veld in Keka | Vangnet J/N |
Related
Keka → Active Directory
Keka to Active Directory integration: domain accounts per office, with expiry on the exit date
Keka → ADP iHCM
Keka to ADP iHCM integration: salary structure, variable payouts and leavers of the Dutch pay group to ADP
Keka → AFAS Profit
Keka to AFAS integration: Dutch employees from Keka in payroll
Keka → DATEV
Keka to DATEV integration: the German entity from Keka to the tax adviser in DATEV