InfraNode

Deutsch | English

InfraNode

Die Open-Data-REST-API für Deutschland: eine HTTP-API ohne API-Key für Open Data zur öffentlichen Infrastruktur, auch als MCP-Server verfügbar.

Deutsche Städte veröffentlichen viel Open Data, aber jede Quelle hat ihr eigenes Format, eigene Felder und eigene Eigenheiten, und für mehrere braucht es eine Registrierung im jeweiligen Portal. InfraNode normalisiert rund 20 Kategorien, Wetter (DWD), Luftqualität (UBA), ÖPNV (inklusive Echtzeit-Abfahrten), Verkehr, Strompreis (SMARD), Bodenrichtwerte (BORIS), Parken, Ladeinfrastruktur, Pegelstände, Demografie, Energie und mehr, für 84+ deutsche Städte hinter einer Schnittstelle. Kein API-Key, kein Konto. Jede Antwort nutzt denselben kanonischen { data, meta }-Umschlag mit Lizenz und Attribution je Datensatz. Dieselben Daten stehen KI-Agenten auch als MCP-Server zur Verfügung (12 schlanke Read-only-Tools über 78 Datenarten). Der Einstieg ist get_city_overview, ein einziger Aufruf: Er liefert einen Katalog aller Datenarten, die es für eine Stadt gibt, dazu einen Live-Auszug der wichtigsten Werte. So sehen Agenten die volle Breite und nicht nur das Wetter. InfraNode wächst laufend, neue Datenarten und Städte kommen regelmäßig dazu.

Zu den Quellen gehören der Deutsche Wetterdienst (DWD), das Umweltbundesamt (UBA), Mobilithek/DELFI, der VBB (Verkehrsverbund Berlin-Brandenburg, CC-BY 4.0), GovData, OpenStreetMap, die Bundesnetzagentur, das KBA und weitere.

Im Einsatz

*Ein einziger get_city_overview("koeln")-Aufruf: aktuelles Wetter, amtliche Luftqualität, DWD-Warnungen, Live-Zugabfahrten mit Verspätungen, Baustellen und der vollständige Datenkatalog der Stadt, aus einem Endpoint ohne API-Key. Jede Stadt lässt sich live ausprobieren auf infranode.dev.*

So funktioniert es

Ein gemeinsamer HTTP-Client fragt die Upstream-Quellen ab, jede Antwort wird auf das kanonische Schema abgebildet, mit ihrer Attribution durch das Lizenz-Gate geführt und in Redis zwischengespeichert (mit Stale-on-Error-Fallback), danach über eine REST-API und einen MCP-Server ausgeliefert. Fällt eine Quelle aus, schlägt sich das in source_status nieder. Der Aufruf selbst scheitert nie daran.

flowchart LR

subgraph SRC["25+ deutsche Open-Data-Quellen"] direction TB S1["DWD, UBA Wetter, Luft"] S2["Mobilithek, DELFI, DB ÖPNV, Echtzeit"] S3["SMARD, BNetzA, MaStR Energie"] S4["BORIS, GovData, OSM, KBA, ..."] end

subgraph CORE["InfraNode-Kern"] direction TB N["Normalisieren ein kanonisches Schema"] --> L["Lizenz-Gate Attribution je Datensatz"] --> C["Redis-Cache Stale-on-Error-Fallback"] end

SRC --> CORE CORE --> API["REST-API infranode.dev/api/v1 84 Städte, ohne API-Key"] CORE --> MCP["MCP-Server mcp.infranode.dev 12 Read-only-Tools"] API --> APPS["Apps & Dashboards"] MCP --> AGENTS["KI-Agenten Claude, ChatGPT"]

Wenn InfraNode dir eine Datenintegration erspart: Ein Stern hilft anderen Entwicklern, das Projekt zu finden.

Schnellstart

Basis-URL https://infranode.dev/api/v1. Kein Key, kein Konto, einfach aufrufen:

curl https://infranode.dev/api/v1/cities/koeln/weather

{

"data": { "city_slug": "koeln", "observed_at": "2026-06-18T13:00:00Z", "source": "dwd", "attribution": { "text": "Datenbasis: Deutscher Wetterdienst", "modified": true }, "payload": { "kind": "weather", "temperature_c": 30.4, "humidity": 43.0, "station_id": "02667" } }, "meta": { "source_status": "ok", "cache_status": "hit", "correlation_id": "..." } }

Jede Antwort folgt demselben { data, meta }-Umschlag: Jeder Datensatz trägt seine attribution (Lizenz und Quelle), und meta.source_status sagt, ob die Upstream-Quelle Daten geliefert hat. Eine tote Quelle degradiert damit sauber, statt den Aufruf scheitern zu lassen.

Über alle Datenarten hinweg sind Feldnamen snake_case und englisch, und dasselbe Konzept heißt immer gleich: post_code, street, house_number, place, name, start, end, distance_km, power_kw, lat, lon. post_code ist immer ein fünfstelliger String (führende Nullen bleiben erhalten), Zeitstempel sind ISO 8601 mit Zeitzone, und ein Wert, den die Quelle nicht liefert, ist null, nie ein leerer String. Manche Antworten führen daneben noch ältere Doppelnamen mit identischen Werten (plz, zip, strasse, hausnummer, ort, city, bezeichnung, beginn, ende, art, dist_km, leistung_kw, einheit_typ, dazu die camelCase-Rohfelder der Autobahn-Verkehrsmeldungen). Diese Namen sind veraltet, nimm die kanonischen.

Tipp: Ruf zuerst /api/v1/cities auf, um die kanonischen Stadt-Slugs zu

finden (etwa koeln, berlin, hamburg), und danach einen stadtbezogenen

Endpoint.

Der {slug} wird tolerant aufgelöst, die exakte ASCII-Form brauchst du also

selten: der deutsche Name mit oder ohne Umlaute, jede Groß- und

Kleinschreibung, gängige englische Exonyme und Kurzformen führen alle auf den

kanonischen Slug (München/münchen/munich/munchen → muenchen,

cologne → koeln, frankfurt → frankfurt-am-main). Ein unbekannter Name

liefert 404 mit dem Hinweis Meintest du ...?, der den nächstliegenden Slug

nennt.

Die vollständige interaktive Referenz und die Abdeckung je Stadt stehen auf infranode.dev. Die InfraNode API im Postman API Network spiegelt jeden Endpoint mit echten Beispielantworten, sodass sich die InfraNode API Postman Collection ohne API-Key direkt im Browser ausprobieren lässt.

SDKs

Keylose Client-Bibliotheken, Quellcode und Issues in eigenen Repos:

Daten (84 Städte, 122 Endpunkte)

Jede Kategorie unten ist ein REST-Endpoint unter /api/v1/cities/{slug}/ . Über MCP kommen dieselben Daten durch 12 schlanke Tools: ein paar benannte (get_city_overview, weather, air_quality, pois, compare, die Live-Tafeln) und ein generisches get_city_resource(slug, resource= ) für jede weitere Datenart (sein resource-Enum listet alle 81 Keys).

Verhalten im Betrieb

• Ohne Key, nur lesend. Keine Zugangsdaten, keine Schreibzugriffe, keine Nutzerkonten.
• Kanonischer Umschlag. { data, meta } mit Status und Attribution je Quelle.
• Sanfte Degradation. Eine ausgefallene Quelle liefert source_status, keinen Fehler.
• Sicher entworfen. SSRF- und Injection-Gates prüfen jede Anfrage, Eingaben laufen gegen feste Allowlists.

Das Sicherheitsmodell steht in SECURITY.md.

Paginierung & Kanal-Voreinstellungen

Listen von Datenarten (charging, energy, events, transit, die OSM-Feature-Endpoints) haben bei gleicher URL eine kanalabhängige Voreinstellung:

• Direktes REST liefert die vollständige Liste in einem Aufruf (limit=null, returned == total, truncated=false).
• GPT Actions (OpenAI-Header) und MCP sind an eine voreingestellte Seitengröße gebunden, damit Antworten für Agenten klein bleiben.
• `limit=all` (oder ?all=1) erzwingt auf jedem Kanal die volle Liste, limit und offset blättern explizit.
• `meta.pagination` (total/returned/limit/offset/truncated) steht auf jedem Kanal, der ausgelieferte Ausschnitt ist also immer nachvollziehbar.

Bei traffic ist die rohe Polyline optional: include=geometry (oder ?full=1) ergänzen, die Standardantwort bleibt schlank.

Stabilität, Changelog & Roadmap

Du baust produktiv auf InfraNode auf? Dann bleib bei Änderungen vorne:

• [Changelog](https://infranode.dev/changelog/) listet jede sichtbare Änderung (neue Datenarten, neue Städte, geändertes Verhalten, Fehlerbehebungen, Deprecations), die neueste zuerst. Per RSS abonnierbar.
• [Roadmap](https://infranode.dev/roadmap/) zeigt das Geplante und die Stabilitätszusage: Die API wächst additiv, der Umschlag bleibt stabil, und Änderungen an bestehenden Antworten werden vorher angekündigt (in der Regel 30+ Tage).
• [Statusseite](https://status.infranode.dev) und die GitHub-Releases decken Verf