SOLVIT API-Anforderungen

Version: 1.1 | Datum: 25.02.2026 | Status: Entwurf

Änderungen v1.1 (Server-Analyse 25.02.2026): Wattform API existiert bereits (Tarife + Bestellungen). Eigene Auftragsstrecke bereits durch Digital Masters in Livewire gebaut. Dokument-Fokus geändert: Nicht „bitte baut eine API“ sondern „bestehende API erweitern“.

1. Zusammenfassung

Ausgangslage — Was existiert bereits?

Update 25.02.2026 (Server-Analyse): Die Analyse des bestehenden Servers (62.108.57.65) hat gezeigt, dass SOLVIT bereits eine REST-API bereitstellt — die sogenannte „Wattform API“ unter wechselprozess.services/solvreg/resources. Digital Masters hat außerdem bereits eine eigene Auftragsstrecke in Livewire gebaut, die das alte SOLVIT-Widget ersetzt. Dieses Dokument wurde entsprechend angepasst.

Was bereits funktioniert (Wattform API)

Die Wattform API wird aktiv in Produktion genutzt und bietet folgende Endpoints:

Endpoint	Methode	Zweck	Status
`/tarife/{plz}/{city}`	GET	Tarife abrufen (PLZ, Stadt, Verbrauch, Straße, Zählertyp)	Produktiv
`/auftraege`	POST	Bestellung abschicken → gibt `auftragsnummer` zurück	Produktiv
Postleitzahlen	GET	PLZ-Validierung + Stadtliste	Produktiv
Straßen	GET	Straßenliste für PLZ/Stadt	Produktiv
Rabattcode validieren	POST	Gutscheincode prüfen	Produktiv
IBAN validieren	POST	IBAN + Kontoinhaber prüfen	Produktiv
Versorger suchen	POST	Vorversorger-Suche	Produktiv

Auth: Header Mandant: starqstrom + Origin: https://starqstrom.de + Referer: https://starqstrom.de/

Was noch fehlt (Erweiterungs-Bedarf)

Die bestehende Wattform API deckt den B2C-Bestellprozess ab, aber für die geplante STARQ Platform fehlen kritische Funktionen:

Status-Webhooks (SOLVIT → Middleware) — Keine Rückmeldung nach Vertragsanlage
Netzentgelt-Export — Keine API für Netzentgelte/Umlagen pro PLZ oder MaLo
Klärfall-Management — Kein Feedback-Kanal bei Problemen (Zähler nicht gefunden, MaLo ungültig)
B2B-Verträge — Kein Endpoint für RLM-Vertragsanlage mit mehreren Zählern/Lieferstellen
Vertragsstatus abfragen — Kein GET-Endpoint für bestehende Aufträge/Vertragsstatus
Kundenservice-Tickets — Keine API für Ticket-Übersicht oder Status

Problem B2B: Drei Medienbrüche (unverändert)

Der B2B-Prozess (RLM-Kunden) läuft weiterhin über manuellen Excel-Export aus HubSpot, Versand per E-Mail an SOLVIT und manuellen Import in das wattform-ERP. Drei Medienbrüche, fehleranfällig, zeitaufwendig und nicht skalierbar.

IST-Zustand vs. SOLL-Zustand

IST-ZUSTAND (Aktuell — Server-Analyse 25.02.2026)
═══════════════════════════════════════════════════════════════════

B2C (SLP) — Eigene Auftragsstrecke EXISTIERT bereits:
  Endkunde ──> starqstrom.de/bestellung/privat (Livewire, 7 Steps)
                               │
                  ┌────────────┼────────────┐
                  ▼                         ▼
           Wattform API               Middleware (DM)
           GET /tarife (Preise)        POST /orders/submit
           POST /auftraege             ──> HubSpot (30+ Props)
                  │
                  ▼
           wattform ERP (Vertrag)

  ✓ Eigene Auftragsstrecke vorhanden
  ✓ Wattform API wird genutzt (Tarife + Bestellungen)
  ✗ Middleware sieht KEINE Preisdetails/Aufschlüsselung
  ✗ Kein Status-Feedback von SOLVIT
  ✗ Keine Netzentgelt-Transparenz


B2B (RLM) — Unverändert problematisch:
  Endkunde ──> Website ──> Middleware (DM) ──> HubSpot (Deal)
                                                     │
                                                     ▼
                                            Excel-Export (manuell)
                                                     │
                                                     ▼
                                            E-Mail an SOLVIT (manuell)
                                                     │
                                                     ▼
                                            wattform ERP (manueller Import)

  Medienbrüche: 3
  Fehlerquellen: Hoch
  Skalierbar: Nein


═══════════════════════════════════════════════════════════════════
SOLL-ZUSTAND (Ziel — STARQ Platform)
═══════════════════════════════════════════════════════════════════

B2C (SLP):
  Website (Statamic) ──> STARQ Platform (Rails)
                               │
                  ┌────────────┼────────────────┐
                  ▼            ▼                ▼
           Wattform API   HubSpot CRM     Dashboard
           (Tarife +      (Contact +      (Transparenz:
            Bestellung)    Deal)           Preise, Status,
                  │                        Netzentgelte)
                  ▼
           + Status-Webhooks (NEU)
           + Netzentgelt-Export (NEU)

  Transparenz: VOLL (Preise, Netzentgelte, Status)
  Status-Rückmeldung: AUTOMATISCH
  Wattform API: ERWEITERT


B2B (RLM):
  Website (Statamic) ──> STARQ Platform (Rails) ──> HubSpot (Deal)
                               │                        │
                               ▼                        ▼
                         MatchPoint              Deal-Stage Trigger
                         (automatisch)                  │
                               │                        ▼
                               ▼                  STARQ Platform
                         Pricing-KPIs                   │
                               │                        ▼
                               └──────────> Wattform API (erweitert)
                                                        │
                                                        ▼
                                                 wattform ERP (Vertrag)

  Medienbrüche: 0
  Automatisierung: VOLL
  Excel-Export: ABGESCHAFFT

Ziel dieses Dokuments

Dieses Dokument beschreibt die API-Erweiterungs-Anforderungen an SOLVIT, damit STARQstrom:

Die bestehende Wattform API über die STARQ Platform (Rails) statt direkt von der Website nutzt (Transparenz)
Die B2B-Vertragserstellung vollautomatisch über die Middleware abwickeln kann (Excel-Export ersetzen)
Status-Rückmeldungen per Webhook erhält (Bestätigung, Klärfall)
Netzentgelt-Daten und Preisaufschlüsselungen per API abrufen kann
Den manuellen Excel-Export für B2B komplett abschaffen kann

Kernaussage: Die Wattform API existiert bereits und wird produktiv genutzt (Tarife + Bestellungen). STARQstrom benötigt Erweiterungen: Status-Webhooks, Netzentgelt-Export, Klärfall-Management und B2B-Vertragsanlage. Alle Daten laufen künftig über die STARQ Platform — nicht mehr direkt von der Website.

2. Analyse des aktuellen SOLVIT-Snippets

Update (Server-Analyse): Das unten beschriebene SOLVIT-Widget ist die ALTE Version. Digital Masters hat bereits eine eigene 7-Schritte-Auftragsstrecke in Livewire gebaut, die direkt die Wattform API aufruft. Das Widget wird NICHT mehr produktiv genutzt. Die folgende Analyse dient als historische Referenz für die Datenpunkte, die SOLVIT erwartet.

Das ehemalige SOLVIT-Widget wurde als JavaScript-Snippet in die STARQstrom-Website eingebettet. Nachfolgend die Analyse der Konfiguration und deren Implikationen.

Widget-Konfiguration

Parameter	Wert / Einstellung	Bedeutung
`Host`	`wechselprozess.services/auftragsstrecke/release/`	SOLVIT-gehostetes Widget, extern geladen
`Mandant`	`"starqstrom"`	Mandanten-Kennung bei SOLVIT
`Versorgungsart`	`"Strom"`	Nur Strom (kein Gas, keine Wärme)
`Tarifart`	`"Haushalt"`	Haushaltskunden (Elektromobilität, Wärmepumpe etc. verfügbar aber deaktiviert)
`Tarifanzahl`	`"Eintarif" / "Zweitarif"`	Auswahl Eintarif (HT) oder Zweitarif (HT/NT)
`Preistyp`	`"AllInklusive"`, `"Brutto"`, `"Einzelbestandteile"`	Darstellung der Preise
`MSB`	`"Nein"`	Keine Messstellenbetreiber-Übernahme
`E-Mail`	Pflichtfeld	Validierung durch SOLVIT
`Telefon`	Optional	Wird abgefragt, aber nicht erzwungen
`Redirect`	Konfigurierbare URL	Weiterleitung nach Abschluss

kWh-Ermittlung über Personenanzahl

Personenanzahl	Jahresverbrauch (kWh)
1 Person	1.500 kWh
2 Personen	2.500 kWh
3 Personen	3.000 kWh
4+ Personen	6.500 kWh

Alternative: Slider-Eingabe von 1.500 bis 6.500 kWh in 100er-Schritten.

Optionale Widget-Features

Gutscheincode: Eingabefeld für Rabattcodes
Rabatt: Rabattanzeige im Preisvergleich
Preis ohne Rabatt: Darstellung des Originalpreises
Bestandskundenabfrage: Prüfung ob Kunde bereits existiert

Rechtliche Zustimmungen (3 Checkboxen)

AGB + Datenschutz + Vollmacht: Zustimmung zu allen drei Dokumenten (Pflicht)
Widerruf: Kenntnisnahme des Widerrufsrechts (Pflicht)
Newsletter: Opt-in für Marketing-Kommunikation (Optional)

Historisch — gelöst: Das Widget war eine Blackbox. Digital Masters hat das Problem gelöst, indem sie eine eigene Livewire-Auftragsstrecke gebaut haben, die die Wattform API direkt aufruft. Dennoch fehlt weiterhin Transparenz über Preisbestandteile (Netzentgelte, Umlagen) und es gibt keine Status-Rückmeldung nach Vertragsanlage. Diese Lücken soll die STARQ Platform schließen.

3. Eigene Auftragsstrecke (bereits vorhanden)

Status: EXISTIERT. Digital Masters hat eine eigene 7-Schritte-Auftragsstrecke in Livewire gebaut. Diese nutzt die Wattform API für Tarife und Bestellungen. Die STARQ Platform (Rails) wird diesen Flow portieren und erweitern, nicht neu erfinden.

Aktueller Flow (Livewire, Server-Analyse verifiziert)

Schritt 1: Standort & Verbrauch (LocationStep)           ✓ EXISTIERT
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  PLZ, Stadt, Straße, Verbrauch (kWh), Zählertyp.
  PLZ-Validierung + Straßenliste via Wattform API.
  URL-Parameter unterstützt: ?zip=54634&usage=3000&type=privat

Schritt 2: Tarifauswahl (TariffSelectionStep)             ✓ EXISTIERT
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  Wattform API aufrufen:
  GET /tarife/{plz}/{city}?strasse=...&stromverbrauch=3000&zaehlertyp=KME
  ──> Tarife mit Preisen werden angezeigt.

Schritt 3: Persönliche Angaben (PersonalDataStep)        ✓ EXISTIERT
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  Anrede, Name, E-Mail, Telefon. Ggf. Firma (B2B).
  Rechnungsadresse falls abweichend.

Schritt 4: Zähler & Lieferbeginn (DeliveryAndMeterStep)  ✓ EXISTIERT
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  Zählernummer, Auftragsgrund (Wechsel/Einzug), Lieferbeginn.
  Vorversorger-Suche via Wattform API.

Schritt 5: Bankverbindung (BankDetailsStep)               ✓ EXISTIERT
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  SEPA/Selbstzahler, IBAN-Validierung via Wattform API.

Schritt 6: Zusammenfassung (SummaryStep)                  ✓ EXISTIERT
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  a) POST /auftraege an Wattform API ──> auftragsnummer
  b) POST /api/hubspot/orders/submit an Middleware ──> HubSpot

Schritt 7: Erfolg (SuccessStep)                           ✓ EXISTIERT
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  Bestätigung mit Auftragsnummer (Format: STRQ-YYYYMMDD-HHMMSS)

Kanäle: /bestellung/privat (B2C) und /bestellung/gewerbe (B2B)

Formularfelder

Feld	Typ	Pflicht	Beispiel	Anmerkung
PLZ	String (5-stellig)	Ja	`54634`	Netzgebiet-Ermittlung
Personenanzahl / kWh	Integer	Ja	`3` oder `3000`	Entweder Personen oder direkte kWh-Eingabe
Tarifart	Enum	Ja	`haushalt`	Aktuell nur Haushalt
Tarifanzahl	Enum	Ja	`eintarif`	Eintarif oder Zweitarif (HT/NT)
Anrede	Enum	Ja	`Herr`	Herr / Frau / Divers
Vorname	String	Ja	`Max`
Nachname	String	Ja	`Mustermann`
E-Mail	String (E-Mail)	Ja	`max@beispiel.de`	Primäre Kommunikation
Telefon / Mobil	String	Nein	`+49 170 1234567`
Straße	String	Ja	`Musterstraße`	Lieferadresse
Hausnummer	String	Ja	`12a`
PLZ (Lieferadresse)	String (5-stellig)	Ja	`54634`	Kann abweichen von Eingabe-PLZ
Stadt	String	Ja	`Bitburg`
Zählernummer	String	Ja	`1EMH0012345678`	Auf dem Zähler ablesbar
Zählerart	Enum	Nein	`digital`	digital / analog / smart
Auftragsgrund	Enum	Ja	`wechsel`	Wechsel (Anbieterwechsel) oder Einzug (Neueinzug)
Lieferbeginn	Date (ISO 8601)	Ja	`2026-04-01`	Mindestens heute, maximal +2 Monate
IBAN	String (IBAN)	Ja	`DE89370400440532013000`	SEPA-Lastschriftmandat
Kontoinhaber	String	Ja	`Max Mustermann`	Falls abweichend vom Kunden
Gutscheincode	String	Nein	`STARQ2026`	Rabatt-/Aktionscode
AGB + Datenschutz	Boolean	Ja	`true`	Muss `true` sein
Widerruf	Boolean	Ja	`true`	Muss `true` sein
Newsletter	Boolean	Nein	`false`	Opt-in Marketing

4. API-Anforderungen

Anforderung 1: Tarife & Preise abrufen EXISTIERT

Richtung: Middleware → SOLVIT | Status: Wattform API GET /tarife/{plz}/{city} ist bereits produktiv.

Was existiert: Tarife mit Preisen abrufen, Parameter: PLZ, Stadt, Straße, Stromverbrauch, Zählertyp, Kanal, Rabattcode.

Was fehlt: Preisaufschlüsselung (Netzentgelte, Umlagen, Steuern als Einzelpositionen) — aktuell wird nur der Gesamtpreis geliefert.

Eigenschaft	Beschreibung
Input	PLZ, kWh (oder Personenanzahl), Tarifart, Tarifanzahl
Output	Liste verfügbarer Tarife mit: Tarifname, Arbeitspreis (ct/kWh), Grundpreis (EUR/Monat), Jahresgesamtkosten (EUR), Gültigkeitszeitraum
Preisdarstellung	Muss unterstützen: AllInklusive (ein Gesamtpreis), Brutto (inkl. MwSt.), Einzelbestandteile (aufgeschlüsselt)
Aufschlüsselung	Netzentgelte, Umlagen, Steuern, Konzessionsabgabe — als einzelne Positionen

Anforderung 2: Vertragsdaten senden EXISTIERT (B2C)

Richtung: Middleware → SOLVIT | Status: Wattform API POST /auftraege ist bereits produktiv (B2C/SLP).

Was existiert: B2C-Bestellung senden (Stammdaten, Bankverbindung, Tarif, Lieferadresse, Rechnungsadresse). Response enthält auftragsnummer.

Was fehlt: B2B-Vertragserstellung mit mehreren Zählern/Lieferstellen/Marktlokationen (aktuell nur manueller Excel-Import).

Alle Kunden- und Vertragsdaten für die Vertragserstellung im wattform-ERP:

Datenkategorie	Felder	Datentyp	Beispiel	Pflicht
Kundendaten (Person)	Anrede, Vorname, Nachname, E-Mail, Telefon, Geburtsdatum	String, Date	`Herr, Max, Mustermann, max@beispiel.de`	Ja
Firmendaten (B2B)	Firmenname, Rechtsform, USt-IdNr., Handelsregister	String	`Muster GmbH, GmbH, DE123456789`	Nur B2B
Zählerdaten	Zählernummer, Zählerart, Zählerstand, Ablesedatum	String, Enum, Float, Date	`1EMH0012345678, digital, 12345.6, 2026-02-25`	Ja (bis zu 10 Zähler)
Marktlokationen	MaLo-ID (33-stellig), Netzgebiet, Spannungsebene	String	`50522423206000000000000000000000001`	Ja (bis zu 10)
Lieferstellen	Straße, Hausnummer, PLZ, Ort, Adresszusatz	String	`Musterstraße 12a, 54634 Bitburg`	Ja (bis zu 9)
Vertragsdaten	Auftragsgrund, Lieferbeginn, Vertragslaufzeit, Tarif-ID	Enum, Date, Integer, String	`wechsel, 2026-04-01, 12, STARQ-H-2026`	Ja
Preisdaten	Arbeitspreis, Grundpreis, Rabatt, Gutscheincode	Float, String	`32.50, 9.90, STARQ2026`	Ja
Zahlungsdaten	IBAN, Kontoinhaber, BIC (optional), Bankname (optional)	String	`DE89370400440532013000, Max Mustermann`	Ja
Rechnungsadresse	Straße, Hausnummer, PLZ, Ort (falls abweichend)	String	`Rechnungsweg 5, 10115 Berlin`	Nein
Netzgebiet	Netzbetreiber, Netzgebiet-ID, Bilanzierungsgebiet	String	`Westnetz GmbH, 10YDE-RWENET---I`	Ja

Anforderung 3: Netzentgelte & Umlagen NEU

Richtung: SOLVIT → Middleware | Status: Existiert noch NICHT. Muss neu gebaut werden.

Regionale Netzentgelte und gesetzliche Umlagen pro Marktlokation / PLZ, die in die Preiskalkulation einfließen.

Komponente	Einheit	Beschreibung
Netznutzungsentgelt	ct/kWh	Entgelt für Netznutzung, regional unterschiedlich
Messstellenbetrieb	EUR/a	Jährliche Kosten für Messstellenbetrieb
KWK-Umlage	ct/kWh	Kraft-Wärme-Kopplung-Umlage
§19 StromNEV-Umlage	ct/kWh	Umlage nach §19 Stromnetzentgeltverordnung
Offshore-Netzumlage	ct/kWh	Umlage für Offshore-Netzanbindung
Konzessionsabgabe	ct/kWh	Abgabe an die Kommune, abhängig von Gemeindegröße
Stromsteuer	ct/kWh	Gesetzlich fixiert (aktuell 2,05 ct/kWh)

Anforderung 4: Status-Rückmeldung NEU

Richtung: SOLVIT → Middleware | Status: Existiert noch NICHT. Muss neu gebaut werden.

Nach der Vertragserstellung muss SOLVIT den Status an die Middleware zurückmelden — entweder synchron als Response oder asynchron per Webhook. Aktuell gibt es keinerlei Rückmeldung nach dem POST /auftraege.

Erfolgsmeldung

Feld	Typ	Beschreibung
`erp_contract_number`	String	Vertragsnummer im wattform-ERP
`energy_identification_code`	String	Energieidentifikationscode (z.B. MaLo-ID)
`status`	Enum	`confirmed`, `pending`, `clarification_needed`
`confirmed_at`	DateTime	Zeitpunkt der Bestätigung

Klärfall (Clarification Needed)

Klärfall-Typ	Beschreibung	Beispiel
`meter_not_found`	Zählernummer im Netzgebiet nicht gefunden	Zählernummer falsch eingegeben
`market_location_invalid`	Marktlokation existiert nicht oder ist ungültig	MaLo-ID veraltet
`network_area_conflict`	PLZ passt nicht zum angegebenen Netzgebiet	Adresse und Netzgebiet widersprüchlich
`iban_invalid`	IBAN-Validierung fehlgeschlagen	Prüfsumme falsch
`address_invalid`	Adresse nicht zustellbar oder nicht existent	Straße/Hausnummer nicht gefunden
`duplicate_contract`	Bereits ein aktiver Vertrag für diese Lieferstelle	Doppelte Bestellung

Anforderung 5: Technische Anforderungen

Anforderung	Details	Priorität
Protokoll	REST API mit JSON (Content-Type: `application/json`)	Muss
Transport	HTTPS mit TLS 1.2 oder höher	Muss
Authentifizierung	API-Key (Header) oder OAuth 2.0 Client Credentials	Muss
Webhooks	Asynchrone Status-Callbacks an konfigurierbare Middleware-URL	Muss
Sandbox	Testumgebung mit realistischen Daten (kein Produktiv-Impact)	Muss
Dokumentation	OpenAPI 3.0 / Swagger-Spezifikation	Muss
Rate Limiting	Dokumentierte Limits (Requests/Minute), HTTP 429 bei Überschreitung	Soll
Idempotenz	POST-Requests mit `Idempotency-Key` Header zur Vermeidung von Duplikaten	Soll
Versionierung	URL-basiert (`/api/v1/`) mit Abwärtskompatibilität	Soll
Encoding	UTF-8, ISO 8601 für Datumsfelder	Muss

5. API-Endpunkte — Vergleich Bestand vs. Erweiterung

Die Wattform API existiert bereits unter wechselprozess.services/solvreg/resources. Nachfolgend der Vergleich zwischen bestehenden und benötigten Endpoints:

Endpoint	Wattform (heute)	STARQ Platform (Bedarf)	Status
Tarife abrufen	`GET /tarife/{plz}/{city}`	Identisch — Auth über Middleware statt direkt	✓ Vorhanden
B2C-Bestellung	`POST /auftraege`	Identisch — Aufruf über Middleware	✓ Vorhanden
PLZ-Validierung	GET (PLZ/Städte)	Identisch	✓ Vorhanden
Straßenliste	GET (Straßen für PLZ/Stadt)	Identisch	✓ Vorhanden
IBAN-Validierung	POST (IBAN + Kontoinhaber)	Identisch	✓ Vorhanden
Rabattcode	POST (Gutscheincode prüfen)	Identisch	✓ Vorhanden
Vorversorger-Suche	POST (Versorger suchen)	Identisch	✓ Vorhanden
B2B-Vertrag (RLM)	—	POST mit mehreren Zählern/MaLos/Lieferstellen	✗ Fehlt
Netzentgelte abrufen	—	GET pro PLZ/MaLo: Netzentgelte, Umlagen, Steuern	✗ Fehlt
Status-Webhook	—	POST Callback: Bestätigung / Klärfall	✗ Fehlt
Vertragsstatus abfragen	—	GET Status eines bestehenden Auftrags	✗ Fehlt
Kundenservice-Tickets	—	GET Ticketübersicht pro Kunde	✗ Fehlt (Phase 2+)

Fazit: 7 von 12 benötigten Endpoints existieren bereits. Die 5 fehlenden Endpoints sind die Erweiterungs-Anforderungen, die mit SOLVIT besprochen werden müssen.

Bestehender Endpunkt: Tarife abrufen (Wattform API)

GET /tarife/{plz}/{city} — Produktiv, verifiziert aus Code

Reale Parameter (aus Server-Analyse)

Parameter	Typ	Pflicht	Beispiel
`strasse`	String (Query)	Nein	`Musterstra%C3%9Fe`
`stromverbrauch`	Integer (Query)	Ja	`3000`
`kanal`	Enum (Query)	Ja	`privat` / `gewerbe`
`waermepumpenoption`	Boolean (Query)	Nein	`false`
`selbstzahlerMsb`	Boolean (Query)	Nein	`false`
`zaehlertyp`	Enum (Query)	Nein	`KME` / `MME` / `IMS`
`rabattcode`	String (Query)	Nein	`STARQ2026`

Auth-Header (verifiziert)

GET /tarife/54634/Bitburg?stromverbrauch=3000&kanal=privat&zaehlertyp=KME
Host: wechselprozess.services/solvreg/resources
Mandant: starqstrom
Origin: https://starqstrom.de
Referer: https://starqstrom.de/

Vorgeschlagene neue Endpunkte (Erweiterung)

Die folgenden Endpunkte sind als Vorschlag für die fehlenden Funktionen zu verstehen. Die finale Spezifikation wird gemeinsam mit SOLVIT erarbeitet.

Neuer Endpunkt 1: Tarife mit Preisaufschlüsselung

GET /api/v1/tariffs — Erweiterung des bestehenden /tarife Endpoints um Einzelbestandteile

Request

GET /api/v1/tariffs?plz=54634&kwh=3000&tarifart=haushalt&tarifanzahl=eintarif
Host: api.solvit.de
Authorization: Bearer {api_key}
Accept: application/json

Response (200 OK)

{
  "plz": "54634",
  "kwh": 3000,
  "tarifart": "haushalt",
  "tarifanzahl": "eintarif",
  "tarife": [
    {
      "tarif_id": "STARQ-GRUEN-2026",
      "name": "STARQstrom Grün",
      "beschreibung": "100% Ökostrom aus deutschen Solar- und Windparks",
      "preise": {
        "arbeitspreis_brutto_ct_kwh": 32.50,
        "arbeitspreis_netto_ct_kwh": 27.31,
        "grundpreis_brutto_eur_monat": 9.90,
        "grundpreis_netto_eur_monat": 8.32,
        "jahreskosten_brutto_eur": 1093.80,
        "jahreskosten_netto_eur": 919.16
      },
      "einzelbestandteile": {
        "energiepreis_ct_kwh": 12.80,
        "netzentgelt_ct_kwh": 8.45,
        "kwk_umlage_ct_kwh": 0.275,
        "strom_nev_umlage_ct_kwh": 0.403,
        "offshore_umlage_ct_kwh": 0.656,
        "konzessionsabgabe_ct_kwh": 1.32,
        "stromsteuer_ct_kwh": 2.05,
        "mehrwertsteuer_prozent": 19.0
      },
      "gueltig_ab": "2026-01-01",
      "gueltig_bis": "2026-12-31",
      "vertragslaufzeit_monate": [12, 24],
      "kuendigungsfrist_wochen": 4
    },
    {
      "tarif_id": "STARQ-FLEX-2026",
      "name": "STARQstrom Flex",
      "beschreibung": "Flexibler Ökostrom ohne Mindestlaufzeit",
      "preise": {
        "arbeitspreis_brutto_ct_kwh": 34.20,
        "arbeitspreis_netto_ct_kwh": 28.74,
        "grundpreis_brutto_eur_monat": 8.50,
        "grundpreis_netto_eur_monat": 7.14,
        "jahreskosten_brutto_eur": 1128.00,
        "jahreskosten_netto_eur": 947.90
      },
      "einzelbestandteile": {
        "energiepreis_ct_kwh": 14.50,
        "netzentgelt_ct_kwh": 8.45,
        "kwk_umlage_ct_kwh": 0.275,
        "strom_nev_umlage_ct_kwh": 0.403,
        "offshore_umlage_ct_kwh": 0.656,
        "konzessionsabgabe_ct_kwh": 1.32,
        "stromsteuer_ct_kwh": 2.05,
        "mehrwertsteuer_prozent": 19.0
      },
      "gueltig_ab": "2026-01-01",
      "gueltig_bis": "2026-12-31",
      "vertragslaufzeit_monate": [0],
      "kuendigungsfrist_wochen": 2
    }
  ],
  "netzgebiet": {
    "netzbetreiber": "Westnetz GmbH",
    "netzgebiet_id": "10YDE-RWENET---I"
  },
  "abfrage_zeitpunkt": "2026-02-25T14:30:00Z"
}

Neuer Endpunkt 2: B2B-Vertrag erstellen (Erweiterung von `POST /auftraege`)

POST /api/v1/contracts — Der bestehende POST /auftraege funktioniert für B2C. Für B2B (RLM) brauchen wir einen erweiterten Endpoint mit mehreren Zählern/MaLos.

Request

POST /api/v1/contracts
Host: api.solvit.de
Authorization: Bearer {api_key}
Content-Type: application/json
Idempotency-Key: starq-ord-2026-00142

{
  "external_id": "STARQ-2026-00142",
  "mandant": "starqstrom",
  "kunde": {
    "typ": "privat",
    "anrede": "Herr",
    "vorname": "Max",
    "nachname": "Mustermann",
    "email": "max@beispiel.de",
    "telefon": "+49 170 1234567",
    "geburtsdatum": "1985-03-15"
  },
  "lieferstelle": {
    "strasse": "Musterstraße",
    "hausnummer": "12a",
    "plz": "54634",
    "ort": "Bitburg",
    "adresszusatz": null
  },
  "zaehler": {
    "zaehlernummer": "1EMH0012345678",
    "zaehlerart": "digital",
    "zaehlerstand": 12345.6,
    "ablesedatum": "2026-02-25"
  },
  "marktlokation": {
    "malo_id": "50522423206000000000000000000000001"
  },
  "vertrag": {
    "tarif_id": "STARQ-GRUEN-2026",
    "auftragsgrund": "wechsel",
    "lieferbeginn": "2026-04-01",
    "vertragslaufzeit_monate": 12,
    "gutscheincode": null
  },
  "zahlung": {
    "iban": "DE89370400440532013000",
    "kontoinhaber": "Max Mustermann",
    "bic": null
  },
  "rechnungsadresse": null,
  "zustimmungen": {
    "agb_datenschutz": true,
    "widerruf": true,
    "newsletter": false
  }
}

Response — Erfolg (201 Created)

{
  "status": "confirmed",
  "external_id": "STARQ-2026-00142",
  "erp_contract_number": "WF-2026-087234",
  "energy_identification_code": "50522423206000000000000000000000001",
  "lieferbeginn": "2026-04-01",
  "tarif": {
    "tarif_id": "STARQ-GRUEN-2026",
    "name": "STARQstrom Grün",
    "arbeitspreis_brutto_ct_kwh": 32.50,
    "grundpreis_brutto_eur_monat": 9.90
  },
  "created_at": "2026-02-25T14:35:12Z"
}

Response — Klärfall (202 Accepted)

{
  "status": "clarification_needed",
  "external_id": "STARQ-2026-00142",
  "erp_contract_number": null,
  "klaerfall": {
    "typ": "meter_not_found",
    "beschreibung": "Zählernummer 1EMH0012345678 konnte im Netzgebiet Westnetz nicht gefunden werden.",
    "betroffene_marktlokation": "50522423206000000000000000000000001",
    "vorschlag": "Bitte Zählernummer prüfen. Möglicherweise beginnt die korrekte Nummer mit 1ESY."
  },
  "created_at": "2026-02-25T14:35:12Z"
}

Neuer Endpunkt 3: Netzentgelte abrufen NEU

GET /api/v1/network-charges

Request

GET /api/v1/network-charges?market_location_id=50522423206
Host: api.solvit.de
Authorization: Bearer {api_key}
Accept: application/json

Response (200 OK)

{
  "market_location_id": "50522423206",
  "netzbetreiber": "Westnetz GmbH",
  "netzgebiet_id": "10YDE-RWENET---I",
  "gueltig_ab": "2026-01-01",
  "gueltig_bis": "2026-12-31",
  "netzentgelte": {
    "netznutzungsentgelt_ct_kwh": 8.45,
    "messstellenbetrieb_eur_a": 20.16,
    "messung_eur_a": 0.00
  },
  "umlagen": {
    "kwk_umlage_ct_kwh": 0.275,
    "strom_nev_umlage_ct_kwh": 0.403,
    "offshore_umlage_ct_kwh": 0.656
  },
  "abgaben": {
    "konzessionsabgabe_ct_kwh": 1.32,
    "stromsteuer_ct_kwh": 2.05
  }
}

Neuer Endpunkt 4: Webhook (Status-Callback) NEU

SOLVIT sendet Status-Updates an eine konfigurierte Middleware-URL. Aktuell gibt es keinerlei Rückmeldung nach Vertragsanlage.

POST {middleware_webhook_url}

Webhook-Payload

POST https://platform.starqstrom.de/webhooks/solvit
Content-Type: application/json
X-Solvit-Signature: sha256={hmac_signature}

{
  "event_type": "contract.status_changed",
  "external_id": "STARQ-2026-00142",
  "erp_contract_number": "WF-2026-087234",
  "status": "confirmed",
  "details": {
    "lieferbeginn": "2026-04-01",
    "netzanmeldung_status": "erfolgreich",
    "netzanmeldung_datum": "2026-02-26T09:00:00Z"
  },
  "timestamp": "2026-02-26T09:15:00Z"
}

Webhook-Payload (Klärfall)

{
  "event_type": "contract.clarification_needed",
  "external_id": "STARQ-2026-00142",
  "erp_contract_number": null,
  "status": "clarification_needed",
  "details": {
    "klaerfall_typ": "meter_not_found",
    "beschreibung": "Zählernummer nicht im Netzgebiet gefunden.",
    "betroffene_marktlokation": "50522423206000000000000000000000001",
    "aktion_erforderlich": "Zählernummer korrigieren und erneut senden."
  },
  "timestamp": "2026-02-25T15:00:00Z"
}

Webhook-Sicherheit: Jeder Webhook-Call muss mit einem HMAC-SHA256-Signatur-Header (X-Solvit-Signature) versehen sein. Die Middleware validiert die Signatur gegen ein gemeinsames Secret, um Manipulationen auszuschließen.

6. Fehlerbehandlung

HTTP-Statuscodes

Code	Bedeutung	Verwendung
`200 OK`	Erfolg	GET-Anfragen, erfolgreiche Abfragen
`201 Created`	Ressource erstellt	Vertrag erfolgreich angelegt
`202 Accepted`	Angenommen, noch in Bearbeitung	Vertrag angenommen, aber Klärfall aufgetreten
`400 Bad Request`	Fehlerhafte Anfrage	Fehlende Pflichtfelder, falsches Format
`401 Unauthorized`	Nicht authentifiziert	Fehlender oder ungültiger API-Key
`404 Not Found`	Ressource nicht gefunden	Tarif-ID, PLZ oder MaLo-ID nicht vorhanden
`422 Unprocessable Entity`	Validierungsfehler	Daten syntaktisch korrekt, aber semantisch ungültig
`429 Too Many Requests`	Rate Limit erreicht	Zu viele Anfragen, `Retry-After` Header beachten
`500 Internal Server Error`	Serverfehler	Unerwarteter Fehler auf SOLVIT-Seite

Fehler-Response-Format

{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Die Anfrage enthält ungültige Daten.",
    "details": [
      {
        "field": "kunde.email",
        "message": "Ungültiges E-Mail-Format.",
        "value": "max@"
      },
      {
        "field": "zaehler.zaehlernummer",
        "message": "Zählernummer muss zwischen 8 und 20 Zeichen lang sein.",
        "value": "12345"
      }
    ],
    "request_id": "req_abc123def456",
    "timestamp": "2026-02-25T14:35:12Z"
  }
}

Klärfall-Typen im Detail

Klärfall-Typ	Code	Beschreibung	Typische Ursache	Empfohlene Aktion
Zähler nicht gefunden	`meter_not_found`	Zählernummer im Netzgebiet unbekannt	Tippfehler, falsches Netzgebiet	Zählernummer beim Kunden rückfragen
Marktlokation ungültig	`market_location_invalid`	MaLo-ID existiert nicht oder ist abgemeldet	Veraltete MaLo-ID, Tippfehler	MaLo-ID beim Netzbetreiber prüfen
Netzgebiet-Konflikt	`network_area_conflict`	PLZ und Netzgebiet passen nicht zusammen	Falsche PLZ oder falsches Netzgebiet	Adressdaten und PLZ prüfen
IBAN ungültig	`iban_invalid`	IBAN-Validierung fehlgeschlagen	Tippfehler, falsche Prüfsumme	IBAN beim Kunden rückfragen
Adresse ungültig	`address_invalid`	Lieferadresse nicht zustellbar	Straße/Hausnr. existiert nicht	Adresse prüfen, ggf. Adresszusatz ergänzen
Duplikat	`duplicate_contract`	Aktiver Vertrag für diese Lieferstelle	Doppelte Bestellung	Kunden kontaktieren, Bestellung prüfen

7. Datenflüsse im Detail

B2C (SLP) — Eigene Auftragsstrecke

Endkunde                Website              STARQ Platform            SOLVIT API            HubSpot
   │                   (Statamic)            (Middleware)                  │                     │
   │  Gibt PLZ +          │                       │                       │                     │
   │  Verbrauch ein       │                       │                       │                     │
   ├─────────────────────>│                       │                       │                     │
   │                      │  POST /api/tariffs    │                       │                     │
   │                      ├──────────────────────>│                       │                     │
   │                      │                       │  GET /api/v1/tariffs  │                     │
   │                      │                       ├──────────────────────>│                     │
   │                      │                       │                       │                     │
   │                      │                       │  Tarife + Preise      │                     │
   │                      │                       │<──────────────────────┤                     │
   │                      │  Tarif-Optionen       │                       │                     │
   │                      │<──────────────────────┤                       │                     │
   │  Sieht Tarife        │                       │                       │                     │
   │  (transparent!)      │                       │                       │                     │
   │<─────────────────────┤                       │                       │                     │
   │                      │                       │                       │                     │
   │  Wählt Tarif +       │                       │                       │                     │
   │  gibt Daten ein      │                       │                       │                     │
   ├─────────────────────>│                       │                       │                     │
   │                      │  POST /api/orders     │                       │                     │
   │                      ├──────────────────────>│                       │                     │
   │                      │                       │                       │                     │
   │                      │                       │──── Daten speichern ──│                     │
   │                      │                       │                       │                     │
   │                      │                       │  POST Contact + Deal  │                     │
   │                      │                       ├─────────────────────────────────────────────>│
   │                      │                       │                       │                     │
   │                      │                       │  POST /api/v1/contracts                     │
   │                      │                       ├──────────────────────>│                     │
   │                      │                       │                       │                     │
   │                      │                       │  Vertrag bestätigt    │                     │
   │                      │                       │<──────────────────────┤                     │
   │                      │                       │                       │                     │
   │                      │                       │  Deal-Status updaten  │                     │
   │                      │                       ├─────────────────────────────────────────────>│
   │                      │                       │                       │                     │
   │                      │  Bestätigungsseite    │                       │                     │
   │                      │<──────────────────────┤                       │                     │
   │  Bestätigung         │                       │                       │                     │
   │<─────────────────────┤                       │                       │                     │

B2B (RLM) — Automatische Übergabe

Endkunde              Website              STARQ Platform         MatchPoint        SOLVIT API        HubSpot
   │                 (Statamic)            (Middleware)               │                 │                │
   │  RLM-Anfrage +      │                      │                    │                 │                │
   │  Lastprofil          │                      │                    │                 │                │
   ├─────────────────────>│                      │                    │                 │                │
   │                      │  POST /api/leads     │                    │                 │                │
   │                      ├─────────────────────>│                    │                 │                │
   │                      │                      │                    │                 │                │
   │                      │                      │  Contact + Company + Deal                            │
   │                      │                      ├──────────────────────────────────────────────────────>│
   │                      │                      │                    │                 │                │
   │                      │                      │  Lastprofil-       │                 │                │
   │                      │                      │  Analyse starten   │                 │                │
   │                      │                      ├───────────────────>│                 │                │
   │                      │                      │                    │                 │                │
   │                      │                      │  Matching-KPIs     │                 │                │
   │                      │                      │  (PV%, Wind%,      │                 │                │
   │                      │                      │   Spot%, kWh)      │                 │                │
   │                      │                      │<───────────────────┤                 │                │
   │                      │                      │                    │                 │                │
   │                      │                      │  Deal-Properties updaten (KPIs)                      │
   │                      │                      ├──────────────────────────────────────────────────────>│
   │                      │                      │                    │                 │                │
   │                      │                      │ [Deal-Stage wechselt zu "Angebot"]                   │
   │                      │                      │<──────────────────────────────────────────────────────┤
   │                      │                      │                    │                 │                │
   │                      │                      │  Preiskalkulation   │                 │                │
   │                      │                      │  (Matching-KPIs +  │                 │                │
   │                      │                      │   Risiken + Marge) │                 │                │
   │                      │                      │                    │                 │                │
   │                      │                      │ [Deal-Stage wechselt zu "Vertrag"]                   │
   │                      │                      │<──────────────────────────────────────────────────────┤
   │                      │                      │                    │                 │                │
   │                      │                      │  POST /api/v1/contracts              │                │
   │                      │                      ├─────────────────────────────────────>│                │
   │                      │                      │                    │                 │                │
   │                      │                      │  Bestätigung / Klärfall              │                │
   │                      │                      │<─────────────────────────────────────┤                │
   │                      │                      │                    │                 │                │
   │                      │                      │  Deal-Status + Vertragsnr. updaten                   │
   │                      │                      ├──────────────────────────────────────────────────────>│

Wichtig: Der B2B-Flow eliminiert den manuellen Excel-Export komplett. Die Deal-Stage in HubSpot steuert den Prozess — wenn der Deal auf „Vertrag“ gesetzt wird, sendet die Middleware automatisch alle Daten an die SOLVIT API. Kein manuelles Eingreifen mehr nötig.

8. Pipeline-Integration

B2C Pipeline (SLP)

Pipeline-Stage	Auslöser	SOLVIT API-Call	Ergebnis
Neuer Lead	PLZ + kWh eingegeben	`GET /api/v1/tariffs`	Verfügbare Tarife anzeigen
Tarif gewählt	Kunde wählt Tarif	—	Tarif-ID in Deal speichern
Daten erfasst	Formular abgeschickt	—	Contact + Deal in HubSpot erstellen
Vertrag erstellt	Bestätigung durch Kunde	`POST /api/v1/contracts`	Vertrag an SOLVIT senden
Bestätigt	SOLVIT-Webhook: `confirmed`	—	Vertragsnummer in Deal, Stage → „Gewonnen“
Klärfall	SOLVIT-Webhook: `clarification_needed`	—	Fehler in Deal, Aufgabe für Vertrieb erstellen

B2B Pipeline (RLM)

Pipeline-Stage	Auslöser	SOLVIT API-Call	Ergebnis
Neuer Lead	RLM-Anfrage über Website	—	Contact + Company + Deal in HubSpot
Lastprofil-Analyse	Lastprofil hochgeladen	—	MatchPoint-Analyse, KPIs in Deal
Netzentgelte abrufen	MaLo-ID bekannt	`GET /api/v1/network-charges`	Netzentgelte in Preiskalkulation
Angebot	Preiskalkulation abgeschlossen	—	Angebot generieren, an Kunden senden
Vertrag	Kunde akzeptiert Angebot	`POST /api/v1/contracts`	Vertrag automatisch an SOLVIT senden
Bestätigt	SOLVIT-Webhook: `confirmed`	—	Vertragsnummer in Deal, Stage → „Gewonnen“
Klärfall	SOLVIT-Webhook: `clarification_needed`	—	Fehler in Deal, Rückfrage an Kunden

9. Phasen-Modell

Die Integration mit SOLVIT erfolgt in Phasen. In Phase 1 berechnet SOLVIT weiterhin die Preise — die Middleware leitet die Daten durch und schöpft Transparenz. In späteren Phasen übernimmt STARQstrom die Preisberechnung selbst.

Aspekt	Phase 1 (Q1/Q2 2026)	Phase 3 (ab Q4 2026)
Wer berechnet Preise?	SOLVIT (Durchleitung)	STARQstrom (eigene Pricing Engine)
Tarifabfrage	Middleware → SOLVIT API → fertige Tarife	Middleware berechnet selbst (EEX + Netzentgelte + Marge)
Netzentgelte	SOLVIT liefert als Teil der Tarifabfrage	Middleware hält eigene Netzentgelt-Datenbank
Börsenpreise	Nicht benötigt (SOLVIT rechnet)	Middleware bezieht EEX/EPEX-Preise direkt
Middleware-Rolle	Datendrehscheibe + Transparenz (Durchleitung)	Vollständige Preiskalkulation + Vertragserstellung
SOLVIT-Rolle	Preisberechnung + ERP (Vertragsverwaltung)	Nur noch ERP (Vertragsverwaltung + Netzanmeldung)
Widget	Abgelöst durch eigene Auftragsstrecke	Nicht mehr vorhanden
Excel-Export	Abgelöst durch API	Nicht mehr vorhanden
Was ändert sich?	Transparenz über alle Daten, keine Blackbox mehr	Volle Kontrolle über Preise, Tarife und Kalkulation

Strategie: Phase 1 schafft die technische Grundlage (API-Anbindung, Datendurchleitung, Transparenz). SOLVIT bleibt Preisrechner, aber STARQstrom sieht und kontrolliert alles. In Phase 3 wird SOLVIT zum reinen ERP-Partner degradiert — die Preishoheit liegt dann bei STARQstrom.

10. Nächste Schritte

Stakeholder-Meeting mit SOLVIT (Benjamin Klink)
Dieses Dokument als Gesprächsgrundlage vorstellen. Bestehende Wattform API anerkennen, Erweiterungsbedarf besprechen: Status-Webhooks, Netzentgelt-Export, B2B-Verträge, Klärfall-Management.
Bestehende Wattform API dokumentieren lassen
SOLVIT bitten, eine offizielle Dokumentation der bestehenden 7 Endpoints bereitzustellen (Response-Formate, Rate Limits, Fehlercodes).
Erweiterungs-Endpoints gemeinsam definieren
Auf Basis dieses Dokuments: Webhooks, Netzentgelt-API, B2B-Vertragsanlage, Vertragsstatus. OpenAPI 3.0 Spezifikation erstellen.
STARQ Platform: Wattform-Connector implementieren
Bestehende Endpoints (Tarife, Bestellungen, Validierungen) in Rails Service Objects wrappen. Auth-Logik (Mandant-Header) portieren.
Sandbox-Umgebung für Erweiterungen
SOLVIT stellt eine Testumgebung für die neuen Endpoints bereit. Bestehende Staging-URL prüfen.
B2C-Umschaltung: Website → STARQ Platform → Wattform
Website sendet Daten an STARQ Platform statt direkt an Wattform API. Parallelbetrieb zum Testen.
B2B-Automatisierung testen
Wenn B2B-Endpoint existiert: HubSpot → STARQ Platform → Wattform API (ersetzt Excel-Export).
Excel-Export abschalten
B2B-Verträge laufen vollautomatisch über die API. Der manuelle Excel-Export wird endgültig abgeschaltet.

Ziel: Die bestehende Wattform API wird über die STARQ Platform geleitet (Transparenz + Dashboard). Die fehlenden Endpoints (Webhooks, Netzentgelte, B2B) werden gemeinsam mit SOLVIT gebaut. Ergebnis: Kein Excel-Export, keine Blackbox. Alle Daten laufen über die STARQ Platform — transparent, automatisiert und skalierbar.

Inhaltsverzeichnis

SOLVIT API-Anforderungen

1. Zusammenfassung

Ausgangslage — Was existiert bereits?

Was bereits funktioniert (Wattform API)

Was noch fehlt (Erweiterungs-Bedarf)

Problem B2B: Drei Medienbrüche (unverändert)

IST-Zustand vs. SOLL-Zustand

Ziel dieses Dokuments

2. Analyse des aktuellen SOLVIT-Snippets

Widget-Konfiguration

kWh-Ermittlung über Personenanzahl

Optionale Widget-Features

Rechtliche Zustimmungen (3 Checkboxen)

3. Eigene Auftragsstrecke (bereits vorhanden)

Aktueller Flow (Livewire, Server-Analyse verifiziert)

Formularfelder

4. API-Anforderungen

Anforderung 1: Tarife & Preise abrufen EXISTIERT

Anforderung 2: Vertragsdaten senden EXISTIERT (B2C)

Anforderung 3: Netzentgelte & Umlagen NEU

Anforderung 4: Status-Rückmeldung NEU

Erfolgsmeldung

Klärfall (Clarification Needed)

Anforderung 5: Technische Anforderungen

5. API-Endpunkte — Vergleich Bestand vs. Erweiterung

Bestehender Endpunkt: Tarife abrufen (Wattform API)

Reale Parameter (aus Server-Analyse)

Auth-Header (verifiziert)

Vorgeschlagene neue Endpunkte (Erweiterung)

Neuer Endpunkt 1: Tarife mit Preisaufschlüsselung

Request

Response (200 OK)

Neuer Endpunkt 2: B2B-Vertrag erstellen (Erweiterung von POST /auftraege)

Request

Response — Erfolg (201 Created)

Response — Klärfall (202 Accepted)

Neuer Endpunkt 3: Netzentgelte abrufen NEU

Request

Response (200 OK)

Neuer Endpunkt 4: Webhook (Status-Callback) NEU

Webhook-Payload

Webhook-Payload (Klärfall)

6. Fehlerbehandlung

HTTP-Statuscodes

Fehler-Response-Format

Klärfall-Typen im Detail

7. Datenflüsse im Detail

B2C (SLP) — Eigene Auftragsstrecke

B2B (RLM) — Automatische Übergabe

8. Pipeline-Integration

B2C Pipeline (SLP)

B2B Pipeline (RLM)

9. Phasen-Modell

10. Nächste Schritte

Neuer Endpunkt 2: B2B-Vertrag erstellen (Erweiterung von `POST /auftraege`)