Gesetzesauswahl wird geladen ...

Gesetz und Fassung

Die Dokumentation kann auf ein Gesetz und eine konkrete hinterlegte Fassung umgeschaltet werden. Die Auswahl wird über die Query-Parameter law und schedule in der URL stabil gehalten.

Fassungsdetails werden geladen ...

API-Handbuch

Dieser Bereich richtet sich an Integrationen, die den Mehrgesetz-Rechner per HTTP ansprechen. Er beschreibt den empfohlenen Ablauf, die wichtigsten Endpunkte und das Fehlerformat.

1. Eingabearten laden

Mit serviceDate zuerst die für den Stichtag verfügbaren inputTypeIds abrufen.

2. Form-Schema laden

Danach für die gewählte Eingabeart alle benötigten Felder und Select-Optionen dynamisch abrufen.

3. Berechnen

Erst mit den aus dem Schema abgeleiteten Werten den eigentlichen /calculate-Request senden.

Dynamischer Modus

Vollständige Integration mit Eingabearten, Form-Schema, Zusatzfeldern und eingabeartspezifischen Select-Optionen.

Statischer Modus

Für Fremd-Dialoge mit fixer Struktur. Der Request enthält nur inputTypeId, die vier Kernfelder, serviceDate, Streitwert und opposingPersons.

Gemeinsame Fachlogik

Beide Wege laufen intern auf dieselbe Berechnung. Der statische Modus ist nur strenger und verarbeitet nicht freigeschaltete Varianten über Defaults, Fallbacks und strukturierte Ignorierhinweise.

Integrationsprinzip

  • Basis-URL: /api
  • Authentifizierung: aktuell keine
  • CORS: offen (Access-Control-Allow-Origin: *)
  • Feldlisten und Optionen nicht hart codieren, sondern immer dynamisch laden.

Empfohlener Ablauf

  1. GET /api/laws/{lawId}/input-types?serviceDate=YYYY-MM-DD
  2. GET /api/laws/ratg/input-types-static?serviceDate=YYYY-MM-DD für statische Fremd-Dialoge
  3. GET /api/laws/{lawId}/form-schema?inputTypeId=...&serviceDate=YYYY-MM-DD
  4. POST /api/laws/{lawId}/calculate
  5. POST /api/laws/ratg/calculate-static für statische Fremd-Dialoge

Wichtige Endpunkte

GET /api

Kurzbeschreibung der API und der verfügbaren Endpunkte.

GET /api/laws/ratg/health

Health-Check mit aktiver Fassung.

GET /api/laws/ratg/versions

Liste aller hinterlegten Fassungen des Gesetzes.

GET /api/laws/ratg/input-types?serviceDate=YYYY-MM-DD

Verfügbare Eingabearten für ein Leistungsdatum.

GET /api/laws/ratg/input-types-static?serviceDate=YYYY-MM-DD

Dasselbe Rückgabeformat wie /input-types, aber nur mit den für /calculate-static freigegebenen Eingabearten.

GET /api/laws/ratg/form-schema?inputTypeId=...&serviceDate=YYYY-MM-DD

Felder, Defaults und Select-Optionen für eine Eingabeart.

POST /api/laws/ratg/calculate

Berechnung auf Basis eines JSON-Request-Bodies.

POST /api/laws/ratg/calculate-static

Kompakter Berechnungsweg für statische Dialoge mit definierter Kernfeld- und Default-Logik.

Stabile Hinweise für Integrationen

  • serviceDate immer als YYYY-MM-DD senden.
  • inputTypeId steuert, welche Felder zulässig und erforderlich sind.
  • Werte wie baseMode, unitRateMode oder ervMode immer aus dem Form-Schema beziehen.
  • Die fachliche Bedeutung dieser Felder ist im Bereich Kernfelder dokumentiert.

Beispiel: Berechnung anstossen

curl -X POST http://localhost:3000/api/laws/ratg/calculate \
  -H 'Content-Type: application/json' \
  -d '{
    "inputTypeId": "TP1I",
    "baseMode": "direct_amount",
    "amount": 10000,
    "serviceDate": "2026-03-25",
    "unitRateMode": "standard",
    "representedPersons": 1,
    "opposingPersons": 1
  }'

Beispiel: Static-Eingabearten laden

curl "http://localhost:3000/api/laws/ratg/input-types-static?serviceDate=2026-03-25"
  • Pflicht-Query-Parameter: keiner
  • serviceDate ist optional und wählt die zum Leistungsdatum passende RATG-Fassung.
  • Die Antwort hat dieselbe Struktur wie /input-types: law, schedule, inputTypes.
  • inputTypes enthält nur Eingabearten, deren staticApi.supported auf true steht.

Beispiel: Statischer Request

curl -X POST http://localhost:3000/api/laws/ratg/calculate-static \
  -H 'Content-Type: application/json' \
  -d '{
    "inputTypeId": "TP1I",
    "serviceDate": "2026-03-25",
    "Streitwert": 10000,
    "representedPersons": 2,
    "baseMode": "direct_amount",
    "unitRateMode": "standard"
  }'

Static-Request-Format

  • Pflichtfelder: inputTypeId, serviceDate
  • Streitwert ist nur dann Pflicht, wenn die gewählte statische Bemessungsgrundlage einen Geld- oder Streitwert für die Berechnung braucht. Die technischen Legacy-Keys disputeValue und amount bleiben kompatibel.
  • Optionale Kernfelder: baseMode, billingContext, unitRateMode, ervMode, representedPersons, opposingPersons
  • representedPersons und opposingPersons fallen ohne Angabe jeweils auf 1 zurück.
  • timeEffortHalfHours kann für zeitbasierte Eingabearten als externer Alias mitgesendet werden.
  • Explizit requestable baseMode-Werte werden pro Eingabeart über staticApi.requestableBaseModes gesteuert.

Defaults im statischen Modus

  • billingContext fällt auf cost_reimbursement zurück, wenn keine Auswahl gesendet wird.
  • unitRateMode fällt auf den eingabeartspezifischen Default oder auf standard zurück.
  • ervMode fällt auf none zurück.
  • baseMode fällt bei wählbaren Bemessungsgrundlagen auf den Eingabeart-Default oder direct_amount zurück.
  • representedPersons und opposingPersons fallen ohne Angabe jeweils auf 1 zurück.

Wichtige Grenzen

  • Nicht freigeschaltete baseMode-Werte werden nicht als Auswahl übernommen, sondern mit not_requestable_in_static_mode markiert und auf den Default-Fall zurückgeführt.
  • Erhöhte Einheitssätze wie double, triple oder quadruple sind im statischen Modus nicht vorgesehen.
  • representedPersons wird nur bei eingabeartspezifisch zulässigem Streitgenossenzuschlag verarbeitet; sonst kommt es mit not_applicable_for_input_type zurück.
  • Zusätzliche oder im statischen Modus nicht benötigte Eingabefelder werden ignoriert und in staticRequest.ignoredFields sowie requestAnalysis.ignoredFields mit Grund zurückgegeben.
Static-API-Matrix wird geladen ...
Unsupported-Liste wird geladen ...

Beispiel: Fehlerformat

{
  "error": {
    "code": "invalid_json",
    "message": "Der Request-Body enthält kein gültiges JSON."
  }
}

Typische Fehlercodes

  • invalid_json: Body ist kein gültiges JSON.
  • unsupported_media_type: Content-Type ist nicht application/json.
  • missing_input_type_id: Query-Parameter inputTypeId fehlt.
  • input_type_not_found: Die gewählte Eingabeart ist unbekannt.
  • invalid_request: Fachliche Validierung oder Parameter ungültig.

FAQ für API-Nutzer

Muss ich Werte wie unitRateMode hart codieren?

Nein. Die zulässigen Varianten kommen immer aus dem Form-Schema für die konkrete Eingabeart.

Wann verwende ich /calculate-static?

Wenn ein Fremdsystem nur einen statischen Dialog ohne nachgeladene Zusatzfelder anbieten kann. Für vollständige Integrationen bleibt /calculate plus /form-schema der bevorzugte Weg.

Wie finde ich die dafür zulässigen Eingabearten?

Über /api/laws/ratg/input-types-static. Der Endpunkt liefert dieselbe Struktur wie /input-types, filtert aber auf die sichere Static-Teilmenge.

Welche Felder liefert /input-types-static zurück?

Genau dieselben Summary-Felder wie /input-types, also insbesondere id, label, group, summary, reference sowie die eingabeartspezifischen Defaults.

Kann ich im statischen Modus jede Bemessungsgrundlage senden?

Nein. Der statische Modus ist bewusst auf die sichere Teilmenge beschränkt, die ohne weitere eingabeartspezifische Zusatzfelder fachlich korrekt berechnet werden kann.

Woher weiss ich, welche Fassung gilt?

Die Auswahl erfolgt über lawId und serviceDate; die API und die Fassungsansicht im Handbuch arbeiten mit derselben Schedule-Logik je Gesetz.

Wo finde ich die Bedeutung einzelner Parameter?

Im Bereich Kernfelder sind wiederverwendete Parameter wie baseMode, billingContext, unitRateMode und ervMode erklärt.

Handbuch-Orientierung

Wähle zuerst den fachlichen Bereich: RATG für anwaltliche Leistungen, GGG für Gerichtsgebühren oder RVG für Gebührenrechnungen nach VV RVG. Danach führen die Einstiege zur passenden Eingabeart, Fassung oder Referenz.

Einstiege werden geladen ...

Eingabeart finden

Wähle im aktuellen Gesetz eine inputTypeId und lies direkt die benötigten Felder samt Defaults.

Kernfeld verstehen

Wiederverwendete Parameter und fachliche Prüffelder sind in der Referenz des aktuellen Gesetzes erklärt.

Fassung prüfen

Über die Gesetzes- und Fassungswahl kannst du die Doku auf einen konkreten RATG- oder GGG-Stand umschalten.

API integrieren

Externe Systeme finden im API-Bereich den empfohlenen Ablauf, Endpunkte und Fehlerformate.

Schnelleinstieg

  • Zuerst serviceDate bzw. Fassung gedanklich festlegen.
  • Dann passende inputTypeId auswählen.
  • Danach Feldbedeutungen über die Kernfeld-Referenz nachschlagen.

Was dieses Handbuch abdeckt

  • Versionierte RATG- und GGG-Fassungen mit serviceDate-Kontext
  • Eingabearten, Felder, Defaults und Select-Optionen
  • GGG-Umsetzungsstatus: TP 1 bis TP 15 inklusive TP 12a und TP 13a umgesetzt, offene Detailpunkte separat ausgewiesen
  • Gemeinsame Kernparameter wie baseMode und unitRateMode

Überblick

Die Daten werden direkt aus der generierten Referenzdatei gelesen.

Dokumentationsdaten werden geladen ...

Dokumentierter Umfang

Die aktuelle Fassung und ihre Eingabearten werden hier zusammengefasst.

Umfang wird geladen ...

Fachkapitel

Diese Kapitel verdichten die wichtigsten fachlichen Leitlinien des Rechners und verknüpfen sie mit den wiederverwendeten Kernfeldern der Referenz.

Fachkapitel werden geladen ...

Kernfelder

Diese wiederverwendeten Felder haben eigene Dokumentationsmetadaten und bilden die gemeinsame Grundlage für mehrere Eingabearten.

Kernfelder werden geladen ...

Eingabearten

Jede Eingabeart hat eine eigene Detailansicht mit stabilem Deep Link. Die Auswahl erfolgt über ein gruppiertes Dropdown; die Detailansicht zeigt Summary, Defaults und das zugehörige Form-Schema. inputTypeIds sind aus dem Tarifpraefix abgeleitete ASCII-IDs, etwa TP2IZ1 fuer TP 2 I Z 1.

Eingabearten werden geladen ...
Detailansicht wird geladen ...

Feld- und Parameterreferenz

Wiederverwendete Kernfelder werden hier als eigene Referenz geführt, unabhängig von einzelnen Eingabearten.

Feldindex wird geladen ...
Feldreferenz wird geladen ...