BambooHR logoAS

Absence reporting (SIVI)

BambooHR to the occupational health service via SIVI: sick leave as absence reports for the Netherlands

With an integration between BambooHR and the occupational health service, approved sick leave of Dutch employees in BambooHR automatically becomes a sick, change or recovery report at the health service, in the SIVI format. An edit to a sickness request in BambooHR goes along as a change to the same absence case, not as a second sickness report.

What the integration does

Organisations that use BambooHR as their HR system and have Dutch employees with an occupational health service often track sickness in BambooHR and also in the health service portal. Whoever edits a sickness request in BambooHR has to remember to do the same at the health service.

  1. At the start we pick the time off types that mean sickness and give the API user rights on those types and on the Dutch employees.
  2. Every hour KoppelHet fetches the requests changed since the previous run, with a small overlap.
  3. Approved sickness of a Dutch employee goes to the health service as a sickness report; a later edit as a change or recovery report.
  4. Once a day the integration compares all ongoing sickness with what the health service holds, to find deleted requests.
  5. The health service's return notification shows in the KoppelHet platform; a rejection or a vanished request becomes a task for HR.
BambooHR → KoppelHet → Arbodienst (SIVI)SOURCEBambooHRTARGETArbodienst (SIVI)Arbodienst (SIVI)KoppelHetmapping · logging · monitoringBambooHR → KoppelHet → Arbodienst (SIVI)SOURCEBambooHRTARGETArbodienst (SIVI)Arbodienst (SIVI)KoppelHetmapping · logging · monitoring
Out: Time off requests of the sick type · Hours or days per date · Dutch employees with employment and department · Employee and employment data without BSN · Return and processing notification from the health service

What to watch for with BambooHR and Arbodienst (SIVI)

  • BambooHR has webhooks for employee changes, but not for time off. KoppelHet therefore requests every hour the requests changed since the previous run, with an overlap, because BambooHR warns that a change can be committed slightly later than the time it carries.
  • When someone edits a request that is still pending, BambooHR replaces it with a new request with a new number. KoppelHet keeps the number of the first request as the absence case, so the health service gets a change and not a duplicate sickness report.
  • A deleted request no longer shows up among the changed requests. The integration therefore compares ongoing sickness in BambooHR daily with what the health service holds; if one is missing, HR gets a task.
  • If the API user may not see an employee or the sick type, BambooHR returns an empty list rather than an error. The sick type is often only visible to administrators. At the start we test with a known sickness request whether the integration really sees it.
  • A request in BambooHR contains the amount per date, in hours or days. From that KoppelHet calculates the absence percentage per day, so an employee working half days does not show as fully sick at the health service.
  • A request can carry notes from the employee and the manager, which sometimes mention a complaint. The integration requests the requests without those notes, so they never even reach KoppelHet.
  • In BambooHR the start boundary of a search window filters on a request's end date and the end boundary on its start date. The daily comparison uses this to also find sickness that began before the window and is still running.

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, architecture and compliance

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.

Price indication · Basic

Leave your work email and you see the price indication right away.

We only use your address to follow up on your question about this integration.

Frequently asked questions

Why not an immediate notification for every sickness request?

BambooHR sends no webhook for time off. The integration therefore checks every hour. For a health service that is well in time.

Do the notes on a request go along?

No. The integration fetches the requests without notes.

What if someone deletes a sickness request in BambooHR?

The daily comparison picks that up, and HR gets a task to settle it with the health service.

Technical details for IT

For those who want to know how it works under the hood: APIs, fields and sources used.

  • BambooHR through GET /api/v1/time_off/requests with updatedSince (ISO 8601, results ascending on updated), type (IDs of the sick type), status (approved, denied, superceded, requested, canceled) and excludeNote; daily with start and end. Fields id, employeeId, start, end, updated, status.status, type.id, amount.unit and dates. Sick types through GET /api/v1/meta/time_off/types. Employees through the employee API with jobInfo and the event-based webhooks for employee.created and employee.updated.
  • The SIVI messages Employments, Employee data and Absence reports go to the health service, with Vangnet J/N (mandatory), organisational unit 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 BambooHRField in Arbodienst (SIVI)Notes
employeeId (of employeeNumber)Identificatie werknemerNo citizen service number
jobInfo (Nederlandse locatie)Identificatie dienstverband
id van de eerste aanvraagVerzuimgeval identificatieStays the same when BambooHR supersedes the request
startDatum eerste verzuimdag
dates (hoeveelheid per dag) en amount.unitPercentage verzuimAgainst the hours per day
end + 1 dagDatum hersteld en Einde verzuim J/N
departmentOrganisatie-eenheid, code
Eigen veld vangnetVangnet J/NBambooHR has no Dutch safety net concept

Related

Which systems do you want to connect?

Tell us which systems you use and what should happen automatically. Together we define the smallest working solution, with a clear design and a quote before building.