Fallanlage
Ziel
Du willst wissen, wie ein Fall entsteht und wie deine Integration mitbekommt, dass es ihn gibt.
Die externe API hat keinen Endpunkt zum Erzeugen eines Falls — es gibt kein
POST /api/external/v1/cases. Fälle entstehen ausschließlich in der Plattform selbst. Deine
Integration findet Fälle, sie legt sie nicht an.
Das ist eine bewusste Grenze: bei der Anlage entscheidet der Server anhand von Standort und Schadenart, welcher Fallabwickler zuständig ist, und prüft Berechtigungen, die an einer real angemeldeten Person hängen. Sollte sich das ändern, steht es hier.
Wie Fälle entstehen
| Weg | Wer | Ergebnisstatus |
|---|---|---|
| Fallformular in der Oberfläche | Standort-Nutzer_in, Fallabwickler_in, Gutachter_in, Admin | WORK_IN_PROGRESS |
| Tally-Webhook (Online-Schadenformular des Standorts) | Kund_in bzw. Standort | WORK_IN_PROGRESS |
| Kundenportal „Kunde hilft mit" (sofern für den Standort verfügbar) | Plattform bei der Einladung | WAITING_FOR_CUSTOMER, nach Portal-Freigabe WORK_IN_PROGRESS |
Ein neuer Fall trägt in allen Fällen mindestens locationId (Standort) und damageType
(THIRD_PARTY_LIABILITY oder OWN_FAULT); der Fallabwickler (caseHandler) wird serverseitig aus
dem Standort abgeleitet. Alles Weitere kann leer sein — genau das ist typischerweise die Lücke, die
deine Integration füllt.
Fälle im Status WAITING_FOR_CUSTOMER erscheinen in deiner Liste, sind aber nicht editierbar:
solange die Kund_in am Portal arbeitet, antwortet PUT /cases/{caseId} mit 409. Warte, bis der Fall
auf WORK_IN_PROGRESS wechselt.
Neue Fälle finden
Der empfohlene Weg: Delta-Abholung
GET /api/external/v1/cases?changedSince=2026-07-20T06:00:00 (Scope cases:read)
Liefert unpaginiert alle Fälle des Mandanten, deren lastModifiedDate am oder nach dem
Zeitstempel liegt, älteste Änderung zuerst. Neu angelegte Fälle sind darin automatisch enthalten —
ihre Anlage ist ihre erste Änderung. Details, Grenzen und die Zeitstempel-Fortschreibung stehen unter
Übersicht und Bearbeitung und
im Integrator-Kochbuch.
Der Weg für den Erstabgleich: seitenweise nach Anlagedatum
GET /api/external/v1/cases?sort=CREATION_DATE&direction=ASC&page=0&size=200
Beim initialen Befüllen deines Zielsystems willst du chronologisch von vorne durchlaufen. size ist
auf 200 gedeckelt; blättere über page, bis page + 1 == totalPages.
Das Feld opened jedes Listeneintrags ist der Anlagezeitpunkt, updated der aus der Fallhistorie
abgeleitete Änderungszeitpunkt.
Was du an einem frischen Fall tun kannst
| Absicht | Endpunkt | Scope |
|---|---|---|
| Vollständige Falldaten lesen | GET /cases/{caseId} | cases:read |
| Felder ergänzen (Aktenzeichen, IBAN, Unfalldaten …) | PUT /cases/{caseId} | cases:write |
| Dokumente anhängen | POST /cases/{caseId}/attachments | attachments:write |
| Sachstand kommentieren | POST /cases/{caseId}/comments | comments:write |
| Fortschritt markieren | PUT /cases/{caseId}/tags | cases:write |
| Freigeben / abschließen / stornieren | PUT /cases/{caseId}/status | cases:status |
Für das Zurückschreiben gilt die Optimistic-Lock-Regel: lies den Fall, ändere die Felder am
gelesenen Objekt, schicke es komplett zurück — inklusive lastModifiedDate und locationId. Siehe
Übersicht und Bearbeitung.
Noch nicht verfügbar
| Fähigkeit | Stand |
|---|---|
Fall anlegen (POST /cases) | existiert nicht |
| Fahrzeugschein-Scan / KI-Extraktion | existiert extern nicht. Der Scope extraction:execute ist im Katalog reserviert, aber kein Endpunkt nutzt ihn |
| Vollmacht/RKÜ, Gutachtenauftrag oder Reparaturablaufplan erzeugen | existiert extern nicht |
| Dokumente signieren oder an die Kund_in senden | existiert extern nicht |
| Fallhistorie lesen | existiert extern nicht |
| Kundenportal steuern | existiert extern nicht |
Der einzige verlässliche Weg, an Dokumente eines Falls zu kommen, ist deshalb die Anhangsliste: Anhänge verwalten.