Pagination & Filter
Alle acht Listen-Endpunkte (GET /v1/employees, /v1/customers, /v1/projects, /v1/tasks, /v1/forms, /v1/submissions, /v1/absences, /v1/worklogs) verwenden Cursor-Pagination.
#Parameter
| Parameter | Beschreibung |
|---|---|
limit | Seitengröße, 1 bis 100. Standard 50. Werte außerhalb ergeben 400 invalid_limit. |
cursor | Opaker Wert aus nextCursor der vorherigen Seite. Ungültige Werte ergeben 400 invalid_cursor. |
updatedAfter | ISO-8601-Zeitpunkt, zum Beispiel 2026-10-01T00:00:00Z. Liefert nur Datensätze, deren updatedAt echt danach liegt. |
#Antwort
{
"data": [ ... ],
"nextCursor": "MjAyNi0xMC0zMFQwOToyNzo1NVp8OGExZDRmN2MtMmI5ZS00YzNhLWE2ZjEtN2UyZDliMGM1ZjE4"
}Datensätze sind aufsteigend nach updatedAt und danach nach id sortiert. Gibt es weitere Datensätze, enthält die Antwort nextCursor. Auf der letzten Seite fehlt nextCursor. Behandeln Sie den Cursor als opak: nicht auswerten und nicht selbst bauen.
#Alle Seiten laden
nextCursor als cursor übergeben und auf jeder Seite dieselben Filter wiederholen:
curl "https://api-test.worklogx.com/api/v1/customers?limit=100" \
-H "Authorization: Bearer wlx_test_YOUR_API_KEY"
curl "https://api-test.worklogx.com/api/v1/customers?limit=100&cursor=NEXT_CURSOR" \
-H "Authorization: Bearer wlx_test_YOUR_API_KEY"#Inkrementeller Abgleich mit updatedAfter
- Beim ersten Lauf die gesamte Liste durchblättern und den höchsten erhaltenen
updatedAt-Wert merken. - Beim nächsten Lauf die Liste mit
updatedAfterauf diesen Wert abfragen und alle Seiten laden.
curl "https://api-test.worklogx.com/api/v1/projects?updatedAfter=2026-10-30T09:27:55Z" \
-H "Authorization: Bearer wlx_test_YOUR_API_KEY"Der Vergleich ist „echt größer“. Ein Datensatz, dessen updatedAt genau dem gespeicherten Wert entspricht, wird nicht erneut geliefert.
#Weitere Filter
| Endpunkt | Filter |
|---|---|
GET /v1/tasks | projectId |
GET /v1/submissions | formId, projectId, customerId, taskId |
GET /v1/absences | employeeId, status, dateFrom, dateTo |
GET /v1/worklogs | employeeId, customerId, projectId, dateFrom, dateTo |
- IDs sind UUIDs. Eine ID einer anderen Organisation ergibt eine leere Seite, keinen Fehler.
dateFromunddateTosind Datumswerte (YYYY-MM-DD). LiegtdateFromnachdateTo, folgt400 invalid_date_range. Bei Abwesenheiten trifft der Filter Abwesenheiten, deren Zeitraum den Bereich überschneidet.statusbei Abwesenheiten ist einer vonPENDING,APPROVED,REJECTED,CANCELLED,REPORTED. Andere Werte ergeben400 invalid_status.