Exporting Timeline Entries
The time export process in Tidsbanken follows a structured and reliable workflow designed to ensure accurate synchronization of approved hours with external systems. The export model is incremental: only new or updated entries are included in each export cycle, and any corrections made after export are handled automatically. Below is a complete explanation of the usage pattern, including the API queries involved in each step.
Summary of the export flow
Approve hours – Only approved entries can be exported.
Prepare entries for export
Run
POST /timelinje/timeeksport/eksportPrepares approved or updated entries.
Retrieve entries
Run
GET /timelinje/timeeksportwith filters as needed.Only unexported entries are returned.
Mark as exported
Send IDs to
PATCH /timelinje/timeeksport/eksportert.
Automatic corrections
Negative adjustment lines and new versions are created when changes occur.
Detailed description of the export flow
Approved hours as the foundation
Only approved time entries are eligible for export. Approval is part of the operational workflow in Tidsbanken and ensures that only finalized and validated data is transferred. Drafts or unapproved entries are never included in the export.
Step 1: Prepare time entries for export
Before time entries can be exported, they must be prepared. This preparation step scans for all approved entries and marks them as ready for export. It also detects previously exported entries that have since been updated or deleted.
If a previously exported entry is changed:
A negative adjustment line is generated to reverse the earlier export
A new updated version of the entry becomes available for export
This ensures the receiving system always reflects the correct and current state of registered hours.
Query used in this step
POST /timelinje/timeeksport/eksportThis request is sent with an empty body. Its purpose is simply to prepare eligible entries.
Step 2: Retrieve time entries that are ready for export
After preparation, the integration retrieves all time entries that are marked as not yet exported. In addition to filtering on Eksportert eq false, many integrations also include a date-based filter to limit results to entries that have been created or updated since the previous export run.
A typical pattern is to filter on EndretDato, using the timestamp of the last successful export cycle.
The value used below is an example.
Query used in this step
GET /timelinje/timeeksport? $select=Id,Dato,AnsattId,ProsjektId,ProsjektLinjeId,ArbeidstypeId,ProduktId,AntallTimer,FakturaTimeAntall& $filter=Eksportert eq false and EndretDato ge 2025-11-30About the EndretDato filter
EndretDato represents the timestamp of the last modification to the time entry.
By specifying EndretDato >= <last export run>, the integration:
avoids scanning the entire dataset
retrieves only entries that are new or changed since the previous run
reduces load for both systems
ensures incremental and efficient export cycles
The date 2025-11-30 in the example is a placeholder.
In production, you would use the timestamp stored from the previous successful export execution.
Step 3: Mark time entries as exported
Once the receiving system has successfully imported the time entries, the integration must return a list of exported IDs back to Tidsbanken. This step is essential to avoid duplicate exports and to ensure future export runs only include new or changed entries.
Query used in this step
PATCH /timelinje/timeeksport/eksportertTypical payload:
{ "ids": [1, 2, 3, 15, 22, 25] }This marks the specified entries as exported so they will not appear again unless modified.
A workflow built for reliability and continuous use
This export pattern is suitable for daily routines, scheduled jobs, or high-frequency automated cycles. The design ensures that:
No entries are exported more than once
All approved entries eventually get exported
Corrections and deletions are always reflected through automatic adjustment lines
Receiving systems always stay synchronized with the authoritative data in Tidsbanken
Because adjustment handling is built into the export model, the integration does not need additional logic for change tracking or historical comparisons.