/v1 in Version 1.0.0.
02.09.2026 – 1.0.0
Vorfälle
POST /incidentsantwortet nun mit422 EMPLOYEE_NOT_ACTIVATED, wenn der referenzierte Mitarbeiter im autorisierten Scope existiert, seine Aktivierung aber noch nicht abgeschlossen ist.- Die Fehlermeldung lautet
The referenced employee is not activated. - Bei dieser Validierung wird kein Vorfall erstellt.
Auswirkungen auf Clients
Wiederholen Sie dieselbe Create-Anfrage nicht, solange die Mitarbeiteraktivierung noch nicht abgeschlossen ist. Senden Sie nach der Aktivierung eine neue Anfrage mit einer neuenX-Request-ID.
28.08.2026 – 1.0.0
Bestellungen
tenantunddivisionIdwurden aus demOrder-Response-Schema entfernt.hrReviewDecisionundOrderHrReviewDecisionwurden durchhrHistoryundOrderHrHistoryersetzt.hrHistory.decisionByenthält nun eine nullable 24-stellige Benutzer-ID. Bei automatisierten Entscheidungen und Entscheidungen per API-Schlüssel ist der Wertnull.- Das in
products[]vonGET /orders,GET /orders/{id}undPOST /orders/{id}/decisionzurückgegebeneOrderProduct-Modell wurde ersetzt. OrderProductenthält nunmodel,vatRate,manufacturerName,articleGroupName,grossAmount,netAmount,service,grossServiceundnetService.description,rateInCentsundserviceRateInCentswurden ausOrderProductentfernt.model,manufacturerName,articleGroupName,service,grossServiceundnetServicesind nullable.vatRateundgrossAmountsind Dezimalzeichenfolgen mit zwei Nachkommastellen;netAmountverwendet vier Nachkommastellen.grossServiceundnetServicesind nullable Dezimalzeichenfolgen mit zwei Nachkommastellen.
Order-Abfragen
tenantunddivisionIdwurden aus den unterstützten Filter- und Sortierfeldern vonGET /ordersentfernt.- Verwenden Sie bei Bedarf
X-Tenant-ID, um eine Order-Abfrage auf einen autorisierten Tenant einzuschränken.
Divisionen
Division.order,DivisionCreate.orderundDivisionPatch.orderwurden vom OpenAPI-Typintegeraufnumbergeändert.- Die bisherige Integer-Beschränkung
multipleOf: 1wurde entfernt.
Auswirkungen auf Clients
Die API-Version bleibt1.0.0 und die produktive Basis-URL bleibt https://api.jobhandy.io/v1. Clients, die Order-Responses deserialisieren, müssen ihre Modelle, DTOs, Mappings, Dezimalverarbeitung, Mocks und Contract Tests aktualisieren. Leiten Sie Tenant oder Division nicht aus Feldern ab, die nicht mehr in der Order-Response enthalten sind.
Ursprünglicher öffentlicher Funktionsumfang
Verfügbare Ressourcen
- Mitarbeiter: auflisten, erstellen, abrufen, aktualisieren
- Bestellungen: auflisten, abrufen, HR-Entscheidung, Attachment-Download
- Vorfälle: auflisten, erstellen, abrufen, aktualisieren, Attachment-Upload
- Divisionen: auflisten, erstellen, abrufen, aktualisieren
- Payroll-Exportdokumente: auflisten, abrufen, herunterladen
- Health: öffentliche Verfügbarkeitsprüfung
Übergreifendes Verhalten
- Authentifizierung über
X-API-Key - optionale Tenant-Auswahl über
X-Tenant-ID, wo dokumentiert - Korrelation über UUID-v4/v7-
X-Request-ID - seitenbasierte Collection-Pagination
- Sortierung nach einem Feld
- Filterausdruckssprache
- Dry-Run-Validierung bei unterstützten Schreibvorgängen
- einheitliches strukturiertes Fehler-Envelope
- Rate-Limit-Response-Header
Das OpenAPI-Dokument enthält kein Veröffentlichungsdatum für diesen Ausgangsstand. Zukünftige Einträge sollen ein ausdrückliches Releasedatum und die Migrationsauswirkungen enthalten.
Format zukünftiger Einträge
Verantwortung des Clients
Vor der Übernahme einer neuen OpenAPI-Datei:- Mit der derzeit vom Client verwendeten Version vergleichen.
- Änderungen an Requests, Responses, Schemas, Enums, Endpoints und Fehlern ermitteln.
- Client-Typen neu erzeugen oder aktualisieren.
- Vertrags- und Abnahmetests ausführen.
- Übernommene Version und Prüfsumme dokumentieren.
Versionierungsrichtlinie
Prüfen Sie, welche Änderungen additiv sind und welche eine Migration erfordern.
