Best Practices
Weniger Anfragen, schnellere Abgleiche, kein 429. Sechs Gewohnheiten, die am meisten sparen, jeweils mit Beispiel zum Kopieren.
Große Seiten abrufen
Ohne limit liefert eine Liste nur 15 Ergebnisse pro Seite, eine lange Liste braucht also viele Anfragen.
Stattdessen so: limit=200 senden, das Maximum. Ein Wert ab 201 wird mit 422 abgelehnt.
curl 'https://www.zep-online.de/zepinstanz/next/api/v1/attendances?limit=200' -H 'Authorization: Bearer {token}' -H 'Accept: application/json'Spart rund 93 % der Anfragen bei einer langen Liste (1 statt 14 für 200 Einträge).
Nur Änderungen abrufen
Wer bei jedem Lauf alles neu lädt, holt Daten, die sich nicht geändert haben.
Stattdessen so: den größten empfangenen modified-Wert merken und beim nächsten Lauf als modified_after senden (Wasserzeichen).
Diese Endpunkte akzeptieren modified_after: /absences, /attendances, /categories, /customers, /employees, /folders, /invoices, /plannings, /projects, /projects/{id}/tasks, /receipts, /receipts-amounts, /resource-plannings, /tickets, /workhour-balances.
curl 'https://www.zep-online.de/zepinstanz/next/api/v1/attendances?modified_after=2026-10-27T15:57:15.000000Z&limit=200' -H 'Authorization: Bearer {token}' -H 'Accept: application/json'Bei /attendances ist der Cursor inklusiv: Datensätze mit genau dem gesendeten modified-Wert kommen erneut zurück, so geht keiner verloren. Ihr Code muss das Duplikat ignorieren. Teilen sich viele Datensätze einen Zeitstempel, setzen Sie mit id_after hinter der zuletzt verarbeiteten ID fort. Alle anderen Endpunkte liefern nur Datensätze, die strikt nach dem Wert geändert wurden. Die Liste ist nicht nach modified sortiert: alle Seiten lesen und das Maximum nehmen; das Wasserzeichen erst nach der letzten Seite speichern. Ausnahme: Bei /plannings verliert der Next-Link vorerst modified_after und limit, folgen Sie ihm dort nicht, sondern senden Sie page selbst und wiederholen Sie die Filter.
Spart rund das gesamte Datenvolumen unveränderter Datensätze, sobald die erste Komplettladung durch ist.
Datumsbereich eingrenzen
Ein Bereich wie 2000 bis 2026 lässt den Server Jahre an Daten lesen und senden, die Sie nicht brauchen.
Stattdessen so: start_date und end_date (YYYY-MM-DD) für den Zeitraum senden, den Sie wirklich brauchen.
curl 'https://www.zep-online.de/zepinstanz/next/api/v1/attendances?start_date=2026-10-01&end_date=2026-10-31&limit=200' -H 'Authorization: Bearer {token}' -H 'Accept: application/json'Spart rund den Anteil der gekürzten Jahre: ein Monat statt 26 Jahre sind etwa 99,7 % weniger Daten.
Rate Limits einhalten
Über den Limits antwortet die API mit 429 und Ihr Abgleich bleibt stehen.
Stattdessen so: Mit X-RateLimit-Remaining das restliche Budget prüfen und bei 429 die Sekunden aus Retry-After abwarten, bevor Sie es erneut versuchen. Limits und Header stehen unter Authentifizierung.
curl -i 'https://www.zep-online.de/zepinstanz/next/api/v1/projects?limit=1' -H 'Authorization: Bearer {token}' -H 'Accept: application/json'Spart rund jeden Wiederholversuch, der ohnehin abgelehnt würde: einmal warten ist billiger als Dauerfeuer.
Flach filtern statt über Eltern-Objekte zu laufen
Eine Anfrage pro Projekt oder Mitarbeiter vervielfacht Ihre Anfragezahl um die Zahl der Eltern-Objekte.
Stattdessen so: den Listen-Endpunkt einmal abfragen und nach der Eltern-ID filtern, zum Beispiel project_id.
curl 'https://www.zep-online.de/zepinstanz/next/api/v1/attendances?project_id=2' -H 'Authorization: Bearer {token}' -H 'Accept: application/json'Spart rund eine Anfrage je Eltern-Objekt, über das Sie nicht mehr laufen.
Generierte Clients
Den HTTP-Code müssen Sie nicht selbst schreiben: Erzeugen Sie einen Client aus der OpenAPI-Spezifikation. Unsere CI erzeugt und kompiliert bei jeder Änderung einen Java-Client aus der Spezifikation.