Release v8.0.17: Änderungen an der REST-API im Changelog →
REST DokumentationChangelog

Changelog

Die Spezifikation der REST-API wird aus dem Quellcode erzeugt und mit jedem ZEP-Release veröffentlicht. Seit der Umstellung auf die generierte Spezifikation beschreibt die Versionsnummer den API-Vertrag (1.x.y), nicht mehr das Produkt-Release: eine brechende Änderung erhöht die Hauptversion und landet in einem neuen /api/v2, additive Änderungen bleiben in v1. Releases nach der Umstellung schreibt die Release-Pipeline aus dem Diff der Spezifikation (Änderungstexte auf Englisch); sie erscheinen nur, wenn sich die API geändert hat. Das Release der Umstellung und alles davor ist von Hand geschrieben.

v8.0.17 · OpenAPI 1.0.0 · 13.10.2026

Fahrzeuge: GET /vehicles (SQ2-1138)

Listet die Fahrzeuge einer Fahrzeugliste; die id ist das Kürzel, das Projektzeiten als vehicle_id tragen. Fahrzeuge liegen in datierten Listen; gültig ist an date (YYYY-MM-DD, Standard heute) die Liste mit dem spätesten Startdatum an oder vor diesem Tag. Vor der ersten Liste ist die Antwort leer. Paginiert über limit, nur lesend. Auf ZEP Clock nicht verfügbar.

Rechnungsersteller: GET /invoices, GET /invoices/{invoice} (SQ2-1135)

Jede Rechnung trägt jetzt creator_username, den Benutzernamen des Mitarbeiters, der das Rechnungsdokument erstellt hat – der Mitarbeiter, den ZEP auf der Rechnung zeigt. Nach einer Korrektur ist es der Mitarbeiter, der die Rechnung korrigiert hat; null, wenn kein Rechnungsdokument gespeichert ist.

Projektzeiten akzeptieren das Fahrzeug-Kürzel: POST /attendances, PATCH /attendances/{id} (SCH-409)

vehicle_id ist das Kürzel des Fahrzeugs (so wie GET es schon liefert, z. B. PKW), ein String mit höchstens 32 Zeichen. Bisher wurde es mit „must be a number“ abgelehnt; eine Zahl hat nur bei numerischen Kürzeln funktioniert und tut das weiterhin (sie wird als Kürzel gelesen). Bitte das Kürzel als String senden.

Die Typänderung von vehicle_id ist als Korrektur geführt, nicht als brechende Änderung: Die Anfrage hat vorher gar kein Fahrzeug angenommen (jeder Wert wurde abgelehnt), daher hängt keine funktionierende Integration am alten Typ. Eine Zahl, die einem numerischen Kürzel entspricht, wird weiterhin angenommen.

  • KORREKTUR POST /attendances, PATCH /attendances/{id}, PUT /attendances/{id}: the vehicle_id request property type changed from number, null to string, null
  • INFO POST /attendances, PATCH /attendances/{id}, PUT /attendances/{id}: the vehicle_id request property’s maxLength was set to 32
  • NEU GET /invoices: added the required property data/items/creator_username to the response with the 200 status
  • NEU GET /invoices/{invoice_number}: added the required property data/creator_username to the response with the 200 status
  • NEU GET /vehicles: endpoint added

v8.0.15 · OpenAPI 1.0.0 · 12.10.2026

Task description limited to 255 characters: POST /projects/{id}/tasks, PUT/PATCH /projects/{id}/tasks/{task_id} (SCH-418)

A description longer than 255 characters answered 500, because the task’s description holds at most 255. It is now rejected with 422 and a validation error on description, and the request schema declares maxLength: 255.

  • INFO POST /projects/{id}/tasks, PATCH /projects/{id}/tasks/{task_id}, PUT /projects/{id}/tasks/{task_id}: the description request property’s maxLength was set to 255

v8.0.11 · OpenAPI 1.0.0 · 10.10.2026

List endpoints sort by orderBy and order

Most list endpoints accepted both parameters and ignored them, so GET /offers?orderBy=status came back in id order. Every list endpoint that documents them now sorts by the record’s key, its writable fields or created/modified, named as in the response (status, name, valid_until, …), order asc or desc. Records with the same value follow in key order (resource plannings: start date, employee, id), so paging stays stable, and links keep the sort. Any other orderBy value sorts by the default, the key (name for locations, the start date for resource plannings); before, it answered 500 on the location, location list and dynamic attribute definition lists. GET /plannings keeps its date order, and GET /projects/{project}/employees its own. No contract change.

v8.0.10 · OpenAPI 1.0.0 · 06.10.2026

GET /resource-plannings liefert die Planungen der Ressourcenplanung: Zeitraum, Einheit (percent oder hours pro Tag) und Wert, dazu die geplanten Stunden je Kalendermonat und gesamt. Filterbar nach date_from/date_to, employee_ids[], project_ids[], customer_numbers[] und modified_after/modified_before. Nur mit dem Modul Ressourcenplanung (MOD_PLANNING_NEXT oder Produktlinie 4 ohne MOD_RESSOURCENPLANUNG); andere Mandanten erhalten 404. GET /plannings bleibt unverändert.

  • NEU GET /resource-plannings: endpoint added

v8.0.9 · OpenAPI 1.0.0 · 06.10.2026

Die REST-API steht auf jeder ZEP-Produktlinie (Produktwelt 2026) ohne das separate Modul MOD_SOAP zur Verfügung; Mandanten mit Produktlinie erhielten vorher 404. Lizenzen ohne Produktlinie brauchen weiterhin MOD_SOAP. Der Vertrag selbst hat sich nicht geändert.

v8.0.7 · OpenAPI 1.0.0 · 25.09.2026 — die generierte Spezifikation wird maßgeblich

  • INFO Das OpenAPI-Dokument wird bei jedem Release aus dem Code (Controller, Form Requests, Resources) erzeugt und hier unverändert veröffentlicht — dieselbe Datei, die die interaktive Referenz rendert. Beschreibungen stehen neben dem Feld, das sie beschreiben, und können nicht mehr auseinanderlaufen.
  • INFO Versionsschema: info.version ist 1.0.0 und folgt ab jetzt dem Vertrag. Die bisherigen Nummern (7.12.49 und älter) spiegelten die ZEP-Produktversion.
  • INFO Alle Referenzseiten dieser Dokumentation (und diese Navigation) werden aus der Spezifikation erzeugt, auf Deutsch und Englisch. Die Antwortbeispiele sind die Feldbeispiele der Spezifikation.
  • INFO Für ZEP Clock wird eine eigene Spezifikation neben der Vollversion veröffentlicht; die Referenzseite hat einen Umschalter, und jede Endpunktseite sagt, ob der Endpunkt auf einer Clock-Instanz verfügbar ist.
  • NEU Alle Update-Operationen akzeptieren PUT als Alias von PATCH — der Router tat das immer, die Dokumentation sagt es jetzt.
  • ABGEKÜNDIGT GET Planung (Legacy-Alias): GET /planning leitet auf GET /plannings um und antwortet mit den Headern Deprecation, Sunset (2027-08-31) und Link. Der Alias wird frühestens am 2027-08-31 entfernt.
  • ABGEKÜNDIGT Kunden: das Objekt status trägt in der Spezifikation deprecated: true und x-sunset: 2027-08-31. Lesen Sie stattdessen inactive; status ist nicht Teil von API v2.
  • FIX Strengere Eingabeprüfung für Anfragen, die vorher kein brauchbares Ergebnis geliefert haben: POST /attendances, PATCH /attendances/{id} und PUT /attendances/{id} nehmen date nur noch als JJJJ-MM-TT (eine Uhrzeit endete in einem Serverfehler, 500); GET /departments lehnt ein leeres start_date oder end_date ab (das ergab nie einen korrekten Filter). Beides antwortet jetzt mit 422; Clients, die bereits reine Datumswerte senden, sind nicht betroffen.
  • FIX Pfadparameter heißen nach dem Schlüssel, über den die API auflöst: /absence-reasons/{name}, /activities/{activity}, /categories/{name}, /customers/{customer_number}/contacts/{id}, /invoices/{invoice_number}. Numerische IDs haben dort nie funktioniert; die Dokumentation behauptete es.
  • FIX created und modified sind an jeder Ressource dokumentiert statt created_at / updated_at, die die API nie geliefert hat.
  • FIX Regelarbeitszeiten liefern holidayCalendar und breakRegulationType mit den englischen Feldnamen, die die API immer zurückgegeben hat (name, note, country, region), nicht mit den deutschen Spaltennamen des alten Dokuments.
  • FIX Nullability und Pflichtfelder jeder Antwort entsprechen den echten Antworten (an einer laufenden Instanz gemessen), und der Filter status[] der Rechnungspositions-Endpunkte deklariert seine Werte als Ganzzahlen.

v7.12.49 (24.07.2026)

Fasst alle Änderungen seit v7.12 (22.06.2026) zusammen.

  • FIX POST Projektzeit anlegen: Die Buchungsregeln werden jetzt vor dem Schreiben geprüft, Verstöße kommen als 422 mit Meldungen je Feld zurück — abgeschlossener Monat, überschrittenes Freigabedatum, Erfassungszeitraum, Nichtarbeitstag oder Feiertag, Beschäftigungszeitraum, Laufzeit von Projekt, Vorgang oder Ticket, überschrittene Planstunden. Die Schnittstelle hat solche Buchungen bisher als einzige angenommen; Weboberfläche, SOAP und Clock lehnen sie seit jeher ab. Wer gültig bucht, merkt nichts.
  • FIX Projektzeiten: Eine Buchung, die um 00:00 endet, gehört zum Folgetag. Diese Grenze geht jetzt in die Überschneidungsprüfung ein, Doppelbuchungen über die Tagesgrenze werden dadurch erkannt und abgelehnt.
  • FIX GET Kunden: status bleibt erhalten und meldet jetzt den tatsächlichen Zustand. Zuvor kam ein inaktiver Kunde als { "value": 1, "label": "Active" } zurück, obwohl die Dokumentation immer 1 = aktiv sagte. Für aktive Kunden ändert sich nichts; wer die Umkehrung im eigenen Client ausgeglichen hat, entfernt diesen Ausgleich.
  • VERALTET Kunden: inactive (boolean) ersetzt status. status wird weiterhin ausgeliefert und bei POST und PATCH akzeptiert; werden beide gesendet, gewinnt inactive. Der Filter ?status= ist ebenfalls veraltet, Ersatz ist ?inactive=. Ein Abkündigungsdatum wird gesondert angekündigt.
  • NEU PATCH Projektzeit aktualisieren
  • NEU DELETE Projektzeit löschen: Prüft die Sperrfristen — abgeschlossener Monat, Freigabedatum, Erfassungszeitraum
  • NEU POST Ansprechpartner anlegen
  • NEU GET Ansprechpartner abrufen
  • NEU PATCH Ansprechpartner aktualisieren
  • NEU DELETE Ansprechpartner löschen
  • NEU PATCH Projektvorgang aktualisieren
  • NEU Projektzeiten: end_date in jeder Antwort — der Kalendertag, an dem die Buchung endet. to allein ist bei einer Buchung bis Tagesende mehrdeutig, weil sie als to = 00:00:00 am Starttag gespeichert wird.
  • NEU Ansprechpartner: department und categories in der Antwort
  • NEU Die Filter modified_after und modified_before auf mehreren Listen-Endpunkten
  • NEU Die Sprachen sk (Slowakisch) und tr (Türkisch)
  • FIX Ein leerer Datumsfilter liefert 422 statt 500 — bei Abwesenheiten und fünf weiteren Endpunkten
  • FIX Mitarbeiter, deren Beschäftigungszeitraum kein Anfangs- oder Enddatum hat, werden nicht mehr als „außerhalb des Beschäftigungszeitraums” abgelehnt. Eine fehlende Grenze bedeutet jetzt offen.
  • FIX default_billability und receipts_billability werden bei POST und PATCH nicht mehr ignoriert
  • FIX Planung: Die konfigurierten Vorgabewerte werden zurückgegeben
  • INFO Neun Operationen, die es längst gab, sind jetzt beschrieben — unter anderem POST /absences, GET /attendances/:id und PATCH /employees/:username. Dazu 66 Felder, die Antworten schon immer enthielten, und zwei Beziehungsschlüssel bei den regulären Arbeitszeiten, die nie so hießen wie dokumentiert.

v7.12 (22.06.2026)

v7.8.74 (09.01.2026)

v7.8.64 (07.01.2026)

  • NEU POST Beleg erstellen: Endpunkt zum Erstellen von Belegen hinzugefügt
  • NEU PATCH Beleg aktualisieren: Endpunkt zum Aktualisieren von Belegen hinzugefügt
  • NEU DELETE Beleg löschen: Endpunkt zum Löschen von Belegen hinzugefügt
  • NEU PUT Anhang hochladen: Endpunkt zum Hochladen von Beleganhängen hinzugefügt
  • NEU DELETE Anhang löschen: Endpunkt zum Löschen von Beleganhängen hinzugefügt

v7.7.0 (07.10.2025)

  • NEU GET Artikel: Endpunkt zum Abrufen von Artikeln hinzugefügt
  • NEU GET Artikel-Details: Endpunkt für einzelnen Artikel hinzugefügt
  • NEU GET Planung: Endpunkt zum Abrufen von Planungseinträgen hinzugefügt
  • NEU GET Projekt-Standorte: Endpunkt für Standorte eines Projekts hinzugefügt
  • NEU PUT Mitarbeiter aktualisieren: Endpunkt zum Aktualisieren von Mitarbeitern hinzugefügt
  • NEU PUT Beschäftigungszeitraum aktualisieren: Endpunkt zum Aktualisieren von Beschäftigungszeiträumen hinzugefügt
  • FIX Korrektur Datentyp plan_can_exceed von boolean zu enum (0-4) in allen Projekt-Endpunkten
  • FIX Fehlende Filterparameter (project_status, project_start_date, project_end_date) für Mitarbeiterprojekte hinzugefügt
  • FIX Fehlendes id Feld in ProjectEmployee Response-Beispielen ergänzt

v7.6.1 (22.09.2025)

v7.4.2 (24.06.2025)

  • NEU GET Projektzeiten: Neue Felder project_release, project_released_at und project_released_by für die Projektzeitfreigabe hinzugefügt
  • NEU GET Projektzeit-Details: Neue Felder für die Projektzeitfreigabe hinzugefügt

v7.4.1 (18.06.2025)

  • INFO OpenAPI-Spezifikation aktualisiert, um alle dokumentierten Endpunkte einzuschließen
  • NEU POST Mitarbeiter erstellen
  • FIX GET Abwesenheiten: Response-Beispiele an aktuelle API-Struktur angepasst, inklusive neuer Felder absence_reason_id, absenceReason Objekt und korrigierte Datumsformate
  • FIX GET Projektzeiten: Response-Beispiele an aktuelle API-Struktur angepasst, Datums-/Zeitformate aktualisiert
  • NEU GET Projektzeit-Details: Dokumentation für einzelne Projektzeit hinzugefügt
  • FIX GET Abteilungen: Response-Beispiele mit neuen Feldern parent_id, manager_count, children_count aktualisiert
  • FIX GET Abteilungs-Details: Response-Struktur mit manager Array statt manager_count aktualisiert
  • FIX GET Abteilungs-Mitarbeiter: Response-Beispiele mit neuem Feld approval_date und Language-Objektstruktur aktualisiert
  • FIX GET Mitarbeiter: Neue Felder categories und dynamicAttributes Arrays hinzugefügt, release_date zu approval_date geändert
  • NEU GET Mitarbeiter-Transponder: Dokumentation für das Abrufen von RFID-Transpondern eines Mitarbeiters hinzugefügt
  • FIX GET Terminals: Response-Beispiele an aktuelle API-Struktur mit Gerätetypen und Statuscodes angepasst
  • FIX GET Terminal-Details: Response-Struktur mit employees und categories Arrays aktualisiert
  • FIX GET Kunden: Response-Struktur mit neuen Feldern vat (ersetzt tax), status als Objekt, department_id, categories und dynamicAttributes Arrays aktualisiert
  • FIX GET Kunden-Details: Response mit neuen Adressfeldern aktualisiert, employees Array entfernt, vollständige priceTables Struktur hinzugefügt
  • FIX GET Angebote: Response-Beispiele aktualisiert und fehlendes Feld order_probability_percent hinzugefügt
  • NEU GET Angebotspositionen: Dokumentation für das Abrufen von Angebotspositionen hinzugefügt
  • FIX GET Belege: Response-Struktur mit vereinfachter receipt_type_id als String statt Objekt aktualisiert, Feldnamen is_amount_gross_or_net zu is_amount_net und is_invoice_amount_gross_or_net zu is_invoice_amount_net geändert
  • FIX GET Beleg-Details: Response-Struktur an Listen-Endpunkt mit gleichen Feldänderungen angepasst
  • FIX GET Beleg-Beträge: Response-Beispiele mit realistischen Daten aktualisiert und neue Felder is_amount_net und is_invoice_amount_net hinzugefügt
  • FIX GET Beleg-Anhänge: Response-Beispiel mit Base64-codierten Dateiinhalten hinzugefügt
  • FIX GET Tickets: Response-Beispiele korrigiert - enthielten fälschlicherweise Belegdaten statt Ticketdaten, categories Array hinzugefügt
  • FIX GET Ticket-Details: Response-Beispiel mit aktuellen Daten aktualisiert
  • FIX GET Ticket-Teilaufgaben: Response-Beispiel mit realistischen Daten aktualisiert
  • FIX GET Ticket-Teilaufgabe Details: Response-Beispiel mit anonymisierten Daten aktualisiert, Überschrift korrigiert
  • NEU GET Ordner: Neuer Endpunkt zum Abrufen von Ordnern hinzugefügt
  • NEU GET Ordner-Dokumente: Neuer Endpunkt zum Abrufen von Dokumenten innerhalb eines Ordners
  • NEU GET Preisgruppen: Neuer Endpunkt zum Abrufen von Preisgruppen hinzugefügt
  • NEU GET Tätigkeiten: Neuer Endpunkt zum Abrufen von Tätigkeiten hinzugefügt
  • NEU GET Fehlgründe: Neuer Endpunkt zum Abrufen von Fehlgründen hinzugefügt
  • NEU GET Kategorien: Neuer Endpunkt zum Abrufen von Kategorien hinzugefügt

v7.4.0 (17.06.2025)

  • NEU Hauptversion-Update mit erweiterten API-Funktionen
  • INFO Aktualisierte API-Dokumentation und verbesserte Endpunkt-Beschreibungen

v6.13.17 (16.09.2024)

v6.13.16 (27.08.2024)

v6.12.5 (06.03.2024)

  • INFO Das Rate-Limiting wurde auf 12000 Requests pro Stunde erhöht. Pro 5 Minuten sind maximal 1000 Requests erlaubt
  • NEU GET Projekte Projektfilter um den Parameter name erweitert
  • FIX GET Projekte: Der Wert plan_hours zeigte keine Planstunden, wenn diese in Vorgängen definiert wurden. Hierzu wurde nun der Wert plan_hours_children hinzugefügt
  • FIX GET Projekte: Das Projekt muss nun nicht mehr komplett innerhalb eines gefilterten Zeitraums liegen. Es reicht, wenn es innerhalb des Zeitraums aktiv war
  • FIX GET Mitarbeiter: Unter bestimmten Umständen trat ein Server Error auf. Dieser Fehler wurde behoben

v6.12.4 (01.03.2024)

  • INFO Kleinere Optimierung der Performance

v6.12.3 (16.02.2024)

v6.12.2 (02.02.2024)

v6.12.1 (14.01.2024)

OpenAPI-SpezifikationProjekte