BORIS-D programmatisch nutzen — der vollständige Leitfaden · Blog

Du baust eine Immobilien-App, ein Bewertungstool oder einen internen Workflow — und der Kunde will Bodenrichtwerte. Die Daten sind öffentlich, das Portal heißt BORIS-D. Eine dokumentierte API gibt es nicht.

Dieser Leitfaden erklärt, wie der Datenfluss hinter BORIS-D tatsächlich funktioniert, welche Fallstricke eine Eigenintegration hat — rechtlich wie technisch — und wie der Weg über eine gepflegte API aussieht. Wer es eilig hat:

curl -H "Authorization: Bearer brw_live_..." \
  "https://api.bodenrichtwert.ai/api/bodenrichtwert?address=Platz%20der%20Menschenrechte%201%2C%2030159%20Hannover"

Was BORIS-D ist (und was nicht)

BORIS-D ist das länderübergreifende Portal der Gutachterausschüsse für Bodenrichtwerte — ein Karten-Frontend, kein Datendienst. Es ist für Menschen gebaut, die zoomen und klicken. Es gibt:

keine öffentlich dokumentierte REST-API,
keine Versionierung und keine Stabilitätsgarantien für die internen Endpunkte,
keinen einheitlichen Datenstandard über alle Bundesländer (Feldnamen, Befüllung und Layer-Struktur variieren),
und keine Vollabdeckung: Bayern führt mit BORIS Bayern ein eigenes Landesportal außerhalb des BORIS-D-Verbunds und ist darüber technisch nicht adressierbar; Schleswig-Holstein und Sachsen fehlt bislang die schriftliche Einwilligung der zuständigen Gutachterausschüsse zur Weiterverarbeitung der Daten.

Der Datenfluss in drei Schritten

Wer eine Adresse in einen Bodenrichtwert übersetzen will, durchläuft konzeptionell drei Stationen:

1. Adress-Vervollständigung (BKG Suggest)

Freitext-Eingaben („königsallee 1 düsseldorf") müssen zu einer eindeutigen, amtlichen Adresse aufgelöst werden. Das übernimmt der Geokodierungsdienst des Bundesamts für Kartographie und Geodäsie (BKG).

2. Geocoding nach UTM32 (EPSG:25832)

Die aufgelöste Adresse wird in Koordinaten übersetzt — aber nicht in das gewohnte WGS84 (lat/lon), sondern in ETRS89/UTM Zone 32N (EPSG:25832), das Koordinatensystem der deutschen Vermessungsverwaltungen. Wer hier WGS84-Koordinaten einsetzt, bekommt keine Fehlermeldung, sondern stillschweigend falsche Treffer — der Klassiker unter den Integrationsfehlern.

3. Flächenabfrage (ArcGIS Identify)

Mit der UTM32-Koordinate fragst du den ArcGIS-Server des jeweiligen Landes-GIS, welche Bodenrichtwert-Zonen den Punkt überlappen. Die Antwort ist rohes ArcGIS-JSON: kryptische Feldkürzel (BRW, STAG, BRN, BZN, GFZ, WGF, …), je nach Bundesland unterschiedlich befüllt, teils mit leeren Pflichtfeldern. Ein Punkt kann mehrere Zonen treffen — etwa eine Sonderbaufläche und eine flächendeckende Forst-Zone.

Für die Anzeige brauchst du die Koordinaten anschließend wieder in WGS84 — die UTM32→WGS84-Rückrechnung (Karney/Krüger) gehört also auch noch in den Stack.

Die Fallstricke einer Eigenintegration

Rechtlich — der wichtigste Punkt zuerst. Die BORIS-D-Nutzungsbedingungen gestatten den Abruf nur über die Funktionen des Portals selbst. Die Daten stehen zwar unter der offenen Datenlizenz Deutschland (dl-de/by-2-0) mit Namensnennungspflicht, der automatisierte Zugriff auf das Portal ist davon aber nicht gedeckt. Für ein Wochenend-Experiment mag das akademisch klingen; für ein Kundenprojekt ist es ein Risiko, das bei einer Eigenintegration allein bei dir liegt. bodenrichtwert.ai stellt die Werte stattdessen normalisiert bereit, mit vollständiger Namensnennung nach dl-de/by-2-0 in jeder Antwort.

Wartung. Die internen Endpunkte können sich jederzeit ändern — ohne Changelog, ohne Deprecation-Fenster. Deine Integration bricht dann nicht in der Entwicklung, sondern im Betrieb beim Kunden. Realistischer Aufwand für einen robusten Eigenbau: 2–3 Tage initial, plus laufende Pflege bei jedem Upstream-Update.

Normalisierung. Alle Bundesländer liefern eigene Varianten. Felder wie gutachterausschuss sind in manchen Ländern schlicht leer, Nutzungsarten-Codes sind upstream teils irreführend belegt. Wer saubere, einheitliche Daten will, schreibt eine Normalisierungsschicht — und pflegt sie pro Bundesland.

Abdeckung. SH, SN und BY musst du selbst erkennen und sauber behandeln, sonst liefert deine App dort stillschweigend nichts — oder Falsches.

Der Weg über die API

bodenrichtwert.ai kapselt genau diese Pipeline — Geocoding, Koordinatentransformation, Identify, Normalisierung, Caching — hinter einem einzigen Endpunkt:

GET https://api.bodenrichtwert.ai/api/bodenrichtwert?address=...&nutzungsart=W
Authorization: Bearer brw_live_...

Die Antwort ist normalisiertes JSON, einheitlich über alle verfügbaren Bundesländer (hier gekürzt — das vollständige Schema steht in der Endpoint-Referenz):

{
  "address_resolved": "Platz der Menschenrechte 1, 30159 Hannover - Mitte",
  "coordinates": { "lat": 52.368, "lon": 9.737 },
  "bodenrichtwerte": [
    {
      "nutzungsart": "Sonderbaufläche",
      "code": "S",
      "brw_euro_pro_m2": 800,
      "stichtag": "2025-01-01",
      "gemeinde": "Hannover",
      "bodenrichtwertnummer": "04305204",
      "zonenbezeichnung": "Regierungsviertel"
    }
  ],
  "attribution": {
    "text": "© Daten der Gutachterausschüsse für Grundstückswerte 2025, dl-de/by-2-0",
    "license_url": "https://www.govdata.de/dl-de/by-2-0",
    "year": 2025
  },
  "disclaimer": "Der Bodenrichtwert ist ein gutachterlicher Orientierungswert — kein Verkehrswert, kein Verkaufspreis, keine Rechtsberatung. Stichtag pro Eintrag beachten."
}

Drei Design-Entscheidungen, die im Projektalltag den Unterschied machen:

Attribution ist Teil der Response. Die Namensnennung nach dl-de/by-2-0 ist Lizenzpflicht — du kannst das attribution-Objekt direkt in dein UI durchreichen, statt sie zu vergessen.
Mehrere Zonen pro Punkt sind ein Array, keine stillschweigend gewählte „beste" Zone. Mit nutzungsart=W filterst du serverseitig auf Wohnbauflächen.
SH/SN/BY antworten mit 451 restricted_state — ein dokumentierter, stabiler Statuscode statt leerer Ergebnisse. Wie du ihn behandelst: Error-451-Guide.

Die übrigen Fehlercodes (400 missing_address, 402 limit_reached, 429 rate_limit_exceeded, 500 processing_error) sind ebenso dokumentiert, die Spec gibt es als OpenAPI 3.1. Antworten werden serverseitig 7 Tage zwischengespeichert; ob eine Antwort aus dem Cache kam, zeigt das Feld cache_hit in der JSON-Response — kein HTTP-Header. Die kurze TTL ist bewusst gewählt, damit Stichtags-Updates zeitnah durchschlagen.

Alternative: MCP statt REST

Landen die Bodenrichtwerte nicht in einer klassischen App, sondern direkt in Claude, einem Agenten-Framework oder einem internen Copiloten, ist die REST-Anbindung oben nicht der einzige Weg. Der MCP-Server unter https://mcp.bodenrichtwert.ai/mcp spricht Streamable HTTP mit OAuth-Discovery — Clients wie Claude Desktop verbinden sich ohne Konfigurationsdatei und ohne dass du das Werkzeug manuell definierst. Was das für KI-Agenten konkret ändert und wann sich MCP gegenüber REST lohnt: MCP-Server-Leitfaden. Für n8n, LangChain, Zapier/Make und Python gibt es fertige Cookbook-Rezepte.

Fazit

Du kannst die BORIS-D-Pipeline selbst nachbauen — die drei Schritte oben sind das vollständige Rezept. Kalkuliere dafür 2–3 Tage Erstaufwand, eine Normalisierungsschicht pro Bundesland, laufende Wartung gegen einen undokumentierten Upstream und die ungeklärte Rechtslage des automatisierten Portal-Zugriffs.

Oder du nimmst den Endpunkt, der genau das als Produkt betreibt: Token generieren, curl-Beispiel von oben einsetzen, erste Response in unter einer Minute — die ersten Abfragen sind im 14-Tage-Trial frei.