Grundlagen

Warum ZVG-Portal.de keine API hat — und wie unsere Schnittstelle das löst

Das offizielle ZVG-Portal veröffentlicht amtliche Zwangsversteigerungsdaten, bietet aber keine Programmierschnittstelle. Dieser Artikel erklärt, warum das so ist, welche technischen Hürden daraus entstehen — und wie eine dedizierte REST-API den Datenzugang für professionelle Nutzer löst.

Veröffentlicht: 3. Juni 2026 · Lesedauer: ca. 7 Min. · Kategorie: Technologie & IntegrationZuletzt aktualisiert: 3. Juni 2026

Einleitung

Wer Zwangsversteigerungsdaten programmatisch verarbeiten will, stößt schnell auf ein fundamentales Problem: Das einzige offizielle Datenportal Deutschlands — zvg-portal.de — bietet keine API. Keine Endpunkte, keine Authentifizierung, keine Dokumentation. Nur eine Website, die für menschliche Besucher gebaut wurde, nicht für Maschinen.

Für gelegentliche Einzelrecherchen ist das verkraftbar. Für Anwendungen, die täglich hunderte Objekte überwachen, Risikomodelle speisen oder automatisierte Alerts versenden sollen, ist es eine strukturelle Sackgasse. Dieser Artikel erklärt, warum das Portal so gebaut ist, was das in der Praxis bedeutet — und wie eine dedizierte REST-API diese Lücke schließt.

Warum das ZVG-Portal keine API hat

Es war nie als Datendienst konzipiert

Das ZVG-Portal wurde am 1. März 2007 als digitale Ergänzung zur analogen Bekanntmachungspflicht eingeführt. Die gesetzliche Grundlage ist § 38 ZVG: Zwangsversteigerungen müssen öffentlich bekannt gemacht werden — das Portal ist der elektronische Kanal dafür.

Das Ziel war Transparenz für die Öffentlichkeit, nicht maschinenlesbarer Datenzugang für Unternehmen. Eine Behördenplattform, die eine Veröffentlichungspflicht erfüllt, folgt anderen Anforderungen als ein Datendienst: Sie muss zugänglich, rechtlich korrekt und stabil sein. Sie muss keine SLAs garantieren, keine JSON-Strukturen definieren und keine Entwicklerdokumentation pflegen.

Das ist kein Versäumnis — es ist eine andere Zielsetzung.

Die technische Architektur macht automatisierten Zugriff schwer

Das Portal setzt auf serverseitig generierte HTML-Seiten mit zustandsabhängiger Session-Verwaltung. Konkret bedeutet das:

Session-Cookies werden beim ersten Seitenaufruf gesetzt und müssen bei jeder Folgeanfrage mitgeführt werden. Standardisierte HTTP-Anfragen ohne Browser-Kontext werden blockiert oder liefern leere Ergebnisse.
Keine strukturierten Endpunkte: Daten lassen sich nur über Formularinteraktionen abrufen — Bundesland auswählen, Gericht auswählen, Suchparameter eingeben. Jede dieser Interaktionen erzeugt einen neuen Seitenzustand, der nicht über eine stabile URL adressierbar ist.
Keine Batch-Abfragen: Es gibt keinen Weg, alle aktuellen Termine bundesweit in einem einzigen Aufruf abzurufen. Wer alle 650 Amtsgerichte abfragen will, muss 650 Einzelanfragen simulieren.
Kein maschinenlesbares Format: Alle Daten liegen als HTML vor — Verkehrswerte, Adressen, Aktenzeichen sind in Tabellenzellen eingebettet, ohne semantische Auszeichnung oder konsistente Struktur.

Das offizielle ZVG-Portal hat keine API und verwendet komplexe Session-Cookies, die einfache automatisierte Anfragen blockieren. Das ist keine Fehlfunktion, sondern eine Konsequenz der zugrundeliegenden Architektur.

Warum Scraping allein keine Lösung ist

Die naheliegende Reaktion auf ein Portal ohne API ist Web Scraping. Tatsächlich existieren dafür bereits Open-Source-Projekte auf GitHub und kommerzielle Scraper-Dienste. Das Problem: Scraping löst das Zugriffsproblem kurzfristig, schafft aber neue.

Scraping-basierte Ansätze haben strukturelle Schwächen, die für professionellen Produktiveinsatz kritisch sind:

Fragilität: Jede Änderung an der HTML-Struktur des Portals — ein umbenanntes CSS-Attribut, eine neue Tabellenstruktur, ein geänderter Formularparameter — kann den Scraper stumm oder fehlerhaft machen. Ohne aktives Monitoring bleibt das oft unbemerkt.

Unvollständigkeit: Scraping erfasst nur das, was zum Zeitpunkt des Abrufs sichtbar ist. Neu eingestellte Termine, kurzfristige Absetzungen oder nachträglich hochgeladene Gutachten werden nur erkannt, wenn der Scraper erneut läuft — und auch dann nur, wenn er die richtige Seite trifft.

Keine Datenqualitätssicherung: Rohe HTML-Exporte enthalten Formatierungsartefakte, inkonsistente Schreibweisen und fehlende Felder. Ein Verkehrswert, der einmal als € 345.000,00 und einmal als 345000 gespeichert ist, erzeugt in nachgelagerten Systemen stille Fehler.

Keine Garantien: Wer auf einem Scraper aufbaut, baut auf Sand. Es gibt kein SLA, keine Vorabankündigung bei Strukturänderungen, keine Fehlerprotokolle.

APIs liefern dagegen einen über längere Zeiträume stabilen Zugang, der in der Regel gut dokumentiert und nach der Ersteinrichtung einfach zu handhaben ist. Die Daten sind vorstrukturiert, zum Beispiel im JSON-Format, sodass sich der Aufwand bei der Datenaufbereitung in Grenzen hält.

Was eine dedizierte REST-API leistet

Die Architektur hinter der Schnittstelle

Eine professionelle ZVG-Datenschnittstelle löst das Problem auf einer anderen Ebene: Sie übernimmt die Komplexität des Portalabrufs intern — Session-Management, Retry-Logik, Parallelabfragen über alle Gerichte — und stellt das Ergebnis als stabilen, dokumentierten REST-Endpunkt bereit.

Der Nutzer interagiert nicht mit dem Portal. Er interagiert mit einer API.

GET /api/v1/verfahren?bundesland=BY&objektart=efh&verkehrswert_min=200000
Authorization: Bearer {API_KEY}

json

{
  "total": 47,
  "page": 1,
  "data": [
    {
      "aktenzeichen": "4 K 12/25",
      "amtsgericht": "Augsburg",
      "bundesland": "Bayern",
      "objektart": "Einfamilienhaus",
      "adresse": {
        "strasse": "Musterstraße 12",
        "plz": "86150",
        "ort": "Augsburg"
      },
      "verkehrswert": 385000,
      "termin": "2025-09-18T10:00:00",
      "mindestgebot_50": 192500,
      "grenze_70": 269500,
      "gutachten_url": "https://...",
      "geocoordinates": { "lat": 48.3705, "lng": 10.8978 }
    }
  ]
}

Was die API leistet, was das Portal nicht kann

Bundesweite Abfragen in Echtzeit: Statt 650 Einzelanfragen liefert ein API-Call gefilterte Ergebnisse über alle Gerichte — nach Bundesland, Objektart, Preisbereich, Postleitzahl oder Radius.

Normalisierte Datenfelder: Verkehrswerte sind typisierte Zahlen, keine Strings. Objektarten folgen einer einheitlichen Taxonomie. Adressen sind geocodiert. Aktenzeichen sind bereinigt und eindeutig.

Abgeleitete Berechnungen: Die gesetzlichen Bietgrenzen nach § 85a ZVG — 50 % und 70 % des Verkehrswerts — werden automatisch berechnet und mitgeliefert. Kein manueller Rechenschritt auf Seiten der Integration.

Webhooks für neue Termine: Statt täglichem Polling können Nutzer Webhooks konfigurieren, die bei neuen Verfahren in definierten Regionen oder Preissegmenten automatisch ausgelöst werden. Kein Termin wird verpasst, kein Cronjob muss gepflegt werden.

Stabile Verfügbarkeit: Die API läuft auf eigener Infrastruktur mit Monitoring, Fehlerprotokollierung und definiertem SLA. Änderungen am ZVG-Portal werden intern absorbiert — die Endpunkte bleiben stabil.

Anwendungsbeispiele

Für eine Bank bedeutet das: Neue Versteigerungsverfahren, bei denen das betroffene Objekt im eigenen Kreditportfolio liegt, werden automatisch erkannt und dem zuständigen Workout-Team gemeldet — ohne manuelle Recherche.

Für ein Immobilienunternehmen bedeutet das: Ein Dashboard zeigt täglich alle neuen Objekte in Zielregionen unterhalb eines definierten Verkehrswerts — als strukturierter Datenfeed, direkt ins CRM integriert.

Für ein PropTech-Startup bedeutet das: Die gesamte Datenbeschaffung ist in einem API-Key und zehn Zeilen Code gelöst. Das Team konzentriert sich auf das Produkt, nicht auf Session-Cookie-Handling.

Fazit & Einordnung

Das ZVG-Portal ist eine amtliche Bekanntmachungsplattform — zuverlässig in seiner Funktion, aber grundlegend ungeeignet für programmatischen Datenzugang. Das ist keine Kritik, sondern eine sachliche Einordnung: Das Portal wurde für einen anderen Zweck gebaut.

Wer Zwangsversteigerungsdaten professionell nutzen will, braucht eine Abstraktionsschicht zwischen der Komplexität des Portals und der eigenen Anwendung. Eine REST-API ist diese Schicht: stabil, dokumentiert, normalisiert — und wartungsfrei auf Seiten des Nutzers.

Der Aufwand, den heute jedes Unternehmen einzeln in Scraping-Infrastruktur und Datenpflege steckt, kann einmal zentral gelöst werden. Das ist die Aufgabe einer dedizierten ZVG-Datenschnittstelle.