Zum Hauptinhalt springen

​
API 2.0.0: Aktiver Vertrag erforderlich

POST /incidents erfordert einen Vertrag mit Status active. Der Status approved reicht nicht aus. Ohne aktiven Vertrag scheitert die Anfrage mit HTTP 422 und EMPLOYEE_HAS_NO_ACTIVE_CONTRACT, auch bei dryRun=true; es wird kein Vorfall erstellt. Klären Sie den Vertragsstatus über den zuständigen Fachprozess, bevor Sie eine neue Anfrage mit neuer X-Request-ID senden. Bestehende Vorfälle bleiben unter ihren bisherigen Lebenszyklus- und Feldbeschränkungen bearbeitbar. Die neue Voraussetzung gilt für das Erstellen. Die Voraussetzung der Mitarbeiteraktivierung bleibt separat dokumentiert; eine Reihenfolge der Validierungsfehler ist nicht festgelegt.

​
API 2.0.0: Sperränderungen bei aktiven Verträgen

Bei PATCH /employees/{id} verbietet ein aktiver Vertrag sowohl blocked: true als auch blocked: false. Enthält die Anfrage blocked, lehnt die API den gesamten Patch mit HTTP 422 und EMPLOYEE_HAS_ACTIVE_CONTRACT ab, auch bei dryRun=true. Andere Felder dieser abgelehnten Anfrage werden nicht übernommen. Auch das erneute Senden des bereits gespeicherten blocked-Werts ist unzulässig. Für reine Profiländerungen lassen Sie blocked vollständig weg. Konfigurieren Sie Serialisierung und Synchronisationsmapping so, dass blocked: false nicht als Standardwert hinzugefügt wird. Beispiel:
Wiederholen Sie einen unveränderten abgelehnten Patch nicht. Klären Sie den Sperrauftrag über den zuständigen Fachprozess oder senden Sie für eine unabhängig beabsichtigte Profiländerung einen neuen Patch ausschließlich mit den gewünschten unterstützten Profilfeldern. Ein erfolgreicher Dry Run reserviert den Vertragsstatus nicht; behandeln Sie dieselbe Validierung beim realen Schreibvorgang. Beginnen Sie mit HTTP-Status, error.code und X-Request-ID. Wiederholen Sie während der Diagnose keine Schreibvorgänge blind.

​
Triage-Ablauf

​
Erreichbarkeit

​
Authentifizierung und Scope

​
401 INVALID_API_KEY

  • Prüfen Sie, ob der Wert aus der vorgesehenen Secret-Version geladen wird.
  • Prüfen Sie auf führende oder nachgestellte Leerzeichen und versehentliche Anführungszeichen.
  • Prüfen Sie in der API-Key-Verwaltung, ob der Key aktiv ist.
  • Prüfen Sie, ob bei der Rotation eine veraltete Runtime übersehen wurde.

​
403 TENANT_NOT_IN_SCOPE

  • Prüfen Sie, ob X-Tenant-ID eine Tenant-ID und kein Unternehmensname oder keine Divisions-ID enthält.
  • Prüfen Sie, ob der ausgewählte Tenant im Key-Scope enthalten ist.
  • Prüfen Sie, ob die referenzierte Ressource zum selben autorisierten Kontext gehört.

​
Mehrdeutige Zuordnung

Senden Sie X-Tenant-ID und beim Erstellen von Mitarbeitern, falls erforderlich, eine zulässige divisionId.

​
Request-Validierung

​
Statuskonflikte

Lesen Sie bei 409 die Ressource erneut, bevor Sie handeln.
  • ORDER_ALREADY_DECIDED: aktuellen finalen Entscheidungsstatus abgleichen.
  • INVALID_STATE_TRANSITION: der aktuelle Lifecycle erlaubt die Anfrage nicht.
  • DIVISION_CYCLE: ausgewählter Parent ist ein Nachfahre der Division.
  • DIVISION_NAME_NOT_UNIQUE_ON_SAME_LEVEL: eindeutigen Geschwisternamen wählen.
  • DUPLICATE_RESOURCE: vorhandene Ressource finden und zuordnen.

​
Timeout nach einem Schreibvorgang

​
Downloadfehler

  • Metadaten erneut lesen und prüfen, dass fileName nicht null ist.
  • Prüfen, ob die ID zum erwarteten Tenant gehört.
  • Status und Content-Type prüfen, bevor die Response auf Datenträger geschrieben wird.
  • Unvollständige Dateien nach 502, 503, 504 oder Netzwerkunterbrechung verwerfen.
  • Transiente Downloadfehler mit begrenztem Backoff wiederholen.

​
Datensatz für die Eskalation

Erfassen Sie:
Fügen Sie niemals den API-Key oder unnötige vollständige personenbezogene Payloads bei.
Zuletzt geändert am 20. Oktober 2026