Glossar

Die Fachbegriffe, die dir über die externe API tatsächlich begegnen — alphabetisch, jeweils mit dem Code-Bezeichner in Klammern. Die deutsche Fachsprache und die englischen Enum-Werte in den DTOs gehören zusammen; dieses Glossar verbindet beide.

Wording-Falle vorweg: der CaseStatus RELEASED heißt in der Oberfläche „In Bearbeitung", WORK_IN_PROGRESS heißt „Entwurf" — siehe Status-Lebenszyklus.

Anhang-Tag (AttachmentTag)

Typisierung eines Fall-Anhangs — 24 Werte, u. a. POA/POA_SIGNED (Vollmacht), OWN_PROCESSING_POA/OWN_PROCESSING_POA_SIGNED (RKÜ), EXPERT_OPINION_ORDER(_SIGNED) (Gutachtenauftrag), REPAIR_PROCESS_PLAN(_SIGNED), FAHRZEUGSCHEIN, PICTURE, INVOICE_REPAIR, ADVISORY, COST_ESTIMATE, OTHER, Default NONE. Die *_SIGNED-Tags sind Workflow-Gates: ohne POA_SIGNED bzw. OWN_PROCESSING_POA_SIGNED verweigert der Server die Freigabe, ohne EXPERT_OPINION_ORDER_SIGNED die Gutachter-Übergabe. Extern hochgeladene Dateien starten immer mit NONE; klassifiziert wird danach per PUT /attachments/{attachmentId}/tag.

API-Key, Grant, Policy (ApiKey, ApiAccessGrant, ApiTenantPolicy)

Die drei Ebenen deines Zugangs: die Policy schaltet einen Mandanten überhaupt für API-Zugriff frei und deckelt die möglichen Scopes; der Grant erlaubt einer konkreten Person, Keys für diesen Mandanten zu erzeugen, und deckelt die Scopes weiter; der Key ist das Credential selbst. Wirksam ist immer die Schnittmenge. Siehe Schlüsselverwaltung.

Eigenbearbeitung / Fremdbearbeitung (OWN_PROCESSING / HANDLER_PROCESSING)

Die Werkstatt wickelt den Fall selbst ab, statt ihn über den Fallabwickler laufen zu lassen (processingType am Fall). Für dich relevant, weil sich dadurch Regeln ändern: die Freigabe verlangt keine signierte Vollmacht, statt einer Vollmacht entsteht eine RKÜ, jede Standort-Person darf abschließen — und Event-Mails werden unterdrückt.

Fall (CaseForm, CaseDTO)

Das zentrale Objekt: ein Unfallschaden-Vorgang mit Beteiligten, Fahrzeug-, Versicherungs- und Schadendaten, adressiert über seine UUID. Extern erreichbar unter /api/external/v1/cases.

Fall-Tag (CaseTag)

Fortschrittsmarkierung am Fall — vier Werte: NONE, LIABILITY_CONFIRMATION_ISSUED (Haftungsbestätigung erteilt), RENTAL_CAR_PRICE_INFORMATION_RECEIVED (Mietwagen-Preisinformation erhalten), ADVANCE_RECEIVED (Vorschuss erhalten). Nicht zu verwechseln mit dem Anhang-Tag. Setzbar über PUT /cases/{caseId}/tags, siehe Fall freigeben und abschließen.

Fallabwickler (Case-Handler, CASE_HANDLER)

Die Organisation, die einen freigegebenen Fall reguliert. Modelliert als Standort-Typ, nicht als Rolle. Am Fall steht der zuständige Fallabwickler im Feld caseHandler; du wählst ihn nicht — der Server leitet ihn aus dem Standort und der Schadenart ab. Die für deinen Mandanten relevanten Fallabwickler liefert GET /case-handlers.

Gutachter / Gutachterbüro (Appraiser, APPRAISER)

Das Sachverständigenbüro, das das Schadengutachten erstellt — ebenfalls ein Standort-Typ. Am Fall stehen expertOffice, expertOfficeCode (inklusive Flag hasApiIntegration), expertEmployee und expertEmployeeCode.

Gutachtenauftrag (EXPERT_OPINION_ORDER)

Der Auftrag der Kund_in an das Sachverständigenbüro. Wird in der Oberfläche als PDF-Formular erzeugt und signiert; als EXPERT_OPINION_ORDER_SIGNED getaggt ist er harte Voraussetzung für die Übergabe an den Gutachter. Erzeugen und Signieren sind extern noch nicht verfügbar.

Haftungsbestätigung (LIABILITY_CONFIRMATION_ISSUED)

Die Bestätigung der gegnerischen Versicherung, die Haftung zu übernehmen. Im System kein Dokument, sondern ein Fall-Tag. Wird es gesetzt, löst die Plattform die Mail LIABILITY_CONFIRMATION an das Postfach des Fall-Standorts aus (abhängig von dessen Mail-Präferenz) — das ist der typische Rückkanal eines Fallabwickler-Systems.

Mandant / Mandanten-Root (tenantRoot)

Der Standort-Teilbaum, auf den dein Key ausgestellt ist. Alles außerhalb existiert für den Key nicht (404). Der Vergleich ist exakt und nie ein bloßer Präfix: musterhaus umfasst musterhaus und musterhaus/nord, aber nicht musterhaus2. Für Fälle hängt die Sicht vom Typ des Roots ab: ein Werkstatt-Mandant (musterhaus) sieht die Fälle, deren Standort im Teilbaum liegt; ein Fallabwickler-Mandant (musterhandler) sieht die Fälle, deren caseHandler im Teilbaum liegt — unabhängig davon, in welcher Werkstatt sie liegen. Fälle in Eigenbearbeitung (OWN_PROCESSING) sind über die Fallabwickler-Sicht nie sichtbar.

Optimistic Lock (lastModifiedDate)

Der Zeitstempel, den du beim Lesen bekommst und beim Schreiben zurückschickst. Weicht er vom Serverstand ab, antwortet der Server mit 400 ALREADY_MODIFIED. Achtung: auch Anhänge, Kommentare und Fall-Tags schreiben einen Historieneintrag und bewegen dadurch lastModifiedDate — nach solchen Aktionen musst du den Fall neu lesen.

Regulierungswerte (EvaluationValues)

Die finanziellen Werte eines Falls: eingereichte und erhaltene Beträge für Reparatur, Mietwagen, Wertminderung und Sachverständigenkosten samt Rechnungsnummern und Daten. Lesbar und schreibbar unter /cases/{caseId}/evaluation-values — Vollersetzung, kein Patch. Kein eigenes Rollen-Gate: jede Mandanten-Sicht, die den Fall sieht, darf lesen und schreiben — typischerweise der Fallabwickler, bei Eigenbearbeitung die Werkstatt selbst (Details).

RKÜ / RKÜB (OWN_PROCESSING_POA)

Das Pendant zur Vollmacht bei Eigenbearbeitung (Reparaturkostenübernahme). Technisch dieselbe Mechanik: eine signierte RKÜ (OWN_PROCESSING_POA_SIGNED) erfüllt dieselbe Freigabe-Voraussetzung wie POA_SIGNED. Zwei Schreibweisen: Oberfläche „RKÜ", Code „RKÜB".

Scope (ApiScope)

Die Berechtigung eines Keys für genau eine Endpunkt-Gruppe, z. B. cases:read. Als Spring-Security-Authority heißt sie SCOPE_cases:read. Der vollständige Katalog steht unter Authentifizierung und Scopes.

Standort (Location, LocationType)

Organisationseinheit und Berechtigungsanker zugleich. Vier Typen: LOCATION (Werkstatt/Betrieb), CASE_HANDLER (Fallabwickler), APPRAISER (Gutachter), ADMIN (Betreiber-Mandant — ADMIN-Standorte liefert die externe API nie aus). Der locationCode ist der Schlüssel; Unterstandorte heißen partner/sub. Unterstandorte erben Fallabwickler, Mail-Präferenz und Eigenbearbeitungs-Flag vom Partner.

Gutachter-System (API-Anbindung)

Ein extern angebundenes Gutachtersystem, an das Fälle bei der Übergabe (HANDED_OVER_APPRAISER) übertragen werden und aus dem fertige Gutachten zurückfließen. Welches System angebunden ist, entscheidet das Gutachterbüro des Falls — es können mehrere sein. Für dich sichtbar nur indirekt: als Statuswechsel, als neue Anhänge am Fall und als aktualisierte Regulierungswerte.

Vollmacht (PoA, POA)

Die von der Kund_in unterschriebene Vollmacht, die den Fallabwickler zur Schadenabwicklung ermächtigt. Als POA_SIGNED getaggt ist sie harte Voraussetzung für Freigabe und Gutachter-Übergabe (außer bei Eigenbearbeitung). Erzeugen, Signieren und Versenden an die Kund_in sind extern noch nicht verfügbar.