78 Prozent aller APIs sprechen JSON. Nicht XML, nicht YAML, nicht irgendein proprietäres Format — JSON. Sechs Datentypen, eine Handvoll Syntaxregeln, null Overhead. Und genau dieses Format hat Deutschland gerade zum Pflichtstandard für seine gesamte digitale Verwaltung erklärt.
Am 18. März 2026 hat der IT-Planungsrat den Deutschland-Stack verbindlich beschlossen — über 50 offene Standards, die Bund, Länder und Kommunen bis 2028 implementieren müssen. Wer sich die Liste anschaut, stellt fest: JSON zieht sich durch wie ein roter Faden. Von der Authentifizierung über die API-Kommunikation bis zur Antragsübermittlung. Dasselbe Format, das mein WordPress-Theme konfiguriert, soll künftig Bürgeranträge validieren.
Das finde ich bemerkenswert. Und es lohnt sich, da genauer hinzuschauen.
Was der Deutschland-Stack eigentlich ist
Der Deutschland-Stack ist kein Produkt und keine Software. Er ist ein Architekturrahmen — sieben Technologie-Schichten von der virtualisierten Infrastruktur bis zu KI-Anwendungen, durchzogen von verbindlichen Standards. Das Bundesministerium für Digitales und Staatsmodernisierung hat ihn entwickelt. Die Leitprinzipien klingen gut: API-First, Open Source, Zero Trust, „Made in EU first“. Die Ambition ist klar — digitale Souveränität, kein Vendor Lock-in, Interoperabilität zwischen Behörden.
Soweit die Theorie. Die Praxis wird zeigen, ob Deutschland das diesmal besser hinbekommt als beim Onlinezugangsgesetz. Die Open Knowledge Foundation hat im Februar 2026 eine lesenswerte Kritik veröffentlicht: Es fehle eine grundlegende IT-Architektur-Skizze. Der Stack sei halt eine Liste an Standards — ohne zu erklären, wie die Komponenten zusammenspielen. Finanzierung? Unklar. Lehren aus dem OZG? Nicht systematisch eingeflossen.
Trotzdem: Die Standardliste selbst ist technisch solide. Und JSON steckt tiefer drin, als man auf den ersten Blick vermuten würde.
JSON im Deutschland-Stack — mehr als ein Datenformat
Offiziell wird JSON neben XML und CSV als Kerndatenformat in der Schicht „Semantische Technologien und Echtzeitanalytik“ gelistet. Das klingt nach einer Fußnote. Ist es aber nicht.
Schaut man sich die mandatierten Standards an, wird klar: JSON ist die Sprache, in der die Schichten miteinander reden. OAuth 2.0, OpenID Connect und JWT — die gesamte Identitäts- und Autorisierungsschicht läuft auf JSON-basierten Protokollen. Die geplante EUDI-Wallet-Integration für digitale Ausweise nutzt SD-JWT und OpenID4VCI — wieder JSON. REST, GraphQL und OpenAPI sind als API-Standards vorgeschrieben — und alle drei transportieren ihre Daten in JSON.
Am deutlichsten wird es bei FIT-Connect, der Bundesplattform für Behördenanträge. Fachdaten-Schemata? JSON Schema. Verschlüsselung? JSON Web Encryption. Schlüsselverwaltung? JSON Web Keys. Authentifizierung? JWT. FIT-Connect ist im Grunde eine JSON-Maschine mit Verwaltungsauftrag.
Nicht alles ist JSON im Stack — XRechnung bleibt XML, die XÖV-Standards sowieso. Aber die Richtung ist eindeutig. Und sie deckt sich mit dem, was ich in meinen eigenen Workflows jeden Tag sehe.
n8n: Workflow-Automatisierung ist JSON-Automatisierung
Ich nutze n8n für meine Automatisierungen, und n8n denkt komplett in JSON. Jedes Datenelement, das zwischen Nodes fließt, ist ein JSON-Objekt mit einem json-Key:
[
{
"json": {
"name": "Jan Wolk",
"email": "jan@somatic-web.de",
"source": "kontaktformular"
}
}
]Der Webhook-Node parst eingehende HTTP-Requests automatisch in strukturierte JSON-Objekte — headers, params, query, body. Zugriff per Expression: {{ $json.body.email }}. Kein XML-Parser, kein Mapping, kein Transformationsschritt. Die Daten kommen rein und sind sofort nutzbar.
Was viele nicht wissen: Auch die Workflow-Definitionen selbst sind JSON-Dateien. Exportierbar, versionierbar über Git, importierbar auf andere Instanzen. Wenn ich einen Workflow in n8n baue, baue ich eigentlich eine JSON-Struktur zusammen — mit einer grafischen Oberfläche drüber.
Über 400 Integrations-Nodes kommunizieren mit externen APIs. Alle über JSON-Payloads. n8n ist ein Paradebeispiel dafür, wie JSON zur universellen Sprache zwischen Systemen geworden ist.
WordPress: Vier JSON-Schichten im CMS
WordPress hat sich in den letzten Jahren still und leise in ein JSON-getriebenes System verwandelt. Vier Schichten, die aufeinander aufbauen.
Die REST API (/wp-json/wp/v2/) liefert alle Inhalte als JSON — Posts, Pages, Taxonomien, Medien. Der Gutenberg-Editor selbst ist eine JavaScript-Anwendung, die auf dieser API aufsetzt. Ohne JSON kein Gutenberg. Und Custom Endpoints lassen sich über register_rest_route() in wenigen Zeilen registrieren.
block.json definiert die Metadaten jedes Gutenberg-Blocks — Name, Kategorie, Attribute, Scripts. WordPress registriert Assets automatisch und lädt sie nur bei Bedarf. Das ist ein konkreter Performance-Vorteil gegenüber der alten PHP-Registrierung.
theme.json ist seit WordPress 5.8 die zentrale Konfigurationsdatei für Block-Themes. Farbpaletten, Typografie, Spacing, Layout-Einstellungen — alles in einer JSON-Struktur. Statt verteilter add_theme_support()-Aufrufe in der functions.php eine einzige, lesbare Datei. WordPress generiert daraus CSS Custom Properties nach dem Muster --wp--preset--color--primary.
Und dann ist da noch ACF Local JSON: Feldgruppen-Definitionen als JSON-Dateien im acf-json/-Ordner des Themes. Per Git versioniert, reisen sie mit jedem Deployment mit — kein manueller Export nötig.
Vier Schichten. Alle JSON. Und alle miteinander verzahnt.
JSON Schema — der stille Qualitätssicherer
Ein Punkt, der im Alltag oft untergeht: JSON Schema ist mittlerweile das Rückgrat der API-Validierung. Über 60 Millionen wöchentliche Downloads. Die OpenAPI-Spezifikation ab Version 3.1.0 ist vollständig JSON-Schema-kompatibel. Auch der Deutschland-Stack schreibt OpenAPI als Standard für API-Dokumentation vor.
In der Praxis heißt das: Ein JSON Schema definiert den Vertrag zwischen API-Produzent und -Konsument. Was darf rein, was nicht? Welche Felder sind Pflicht, welche Typen erlaubt? Das API-Gateway prüft eingehende Requests gegen das Schema und lehnt ungültige Payloads ab — bevor sie die Anwendungslogik erreichen.
Denselben Mechanismus nutzt FIT-Connect für Behördenanträge. Und denselben Mechanismus nutze ich in n8n, wenn ich Webhook-Eingaben validiere. Selbes Prinzip, andere Dimension.
Warum JSON und nicht XML?
Diese Frage stellt heute kaum noch jemand, aber sie ist trotzdem relevant — gerade weil der Deutschland-Stack beide Formate enthält. Die Antwort hat weniger mit technischer Überlegenheit zu tun und mehr mit Pragmatismus.
JSON bildet direkt auf Objekte in JavaScript, Python, PHP und praktisch jeder anderen Sprache ab. JSON.parse() — fertig. Kein DOM-Parser, keine SAX-Events, keine Namespace-Hölle. Ein JSON-Objekt mit einem Gast sieht so aus: {"name":"Alice"}. Das XML-Äquivalent braucht öffnende Tags, schließende Tags, optional Attribute, Namespaces, Entity-Referenzen. Mehr Syntax, weniger Signal.
Douglas Crockford, der JSON 2001 nicht erfunden, sondern — wie er selbst sagt — entdeckt hat, hat die Spezifikation auf eine einzige Seite mit ein paar Railroad-Diagrammen gepackt. Die passt auf json.org. Bis heute. Sechs Datentypen: String, Number, Object, Array, Boolean, Null. Das ist alles.
XML bleibt da relevant, wo es hingehört: dokumentenzentrierte Formate wie XRechnung, XSLT-Transformationen, strenge Schema-Validierung mit XSD. Der Deutschland-Stack kennt beides — JSON als modernes Austauschformat, XML in Altsystemen und Fachstandards. Das ist pragmatisch. Das passt.
Das größere Bild
JSON-LD treibt strukturierte Daten für Suchmaschinen — Google empfiehlt es ausdrücklich als bevorzugtes Format. GeoJSON standardisiert Geodaten. JWT authentifiziert Nutzer auf jeder großen Cloud-Plattform. PostgreSQL speichert JSON nativ als JSONB mit Indexierung. Und in der KI-Welt ist JSON das Ein- und Ausgabeformat für jede relevante API — von OpenAI über Anthropic bis Google. Structured Outputs, also garantierte JSON-Schema-Konformität bei LLM-Antworten, waren einer der wichtigsten Durchbrüche in den letzten zwei Jahren.
Alles JSON. Überall JSON.
Was das für die Praxis bedeutet
Der Deutschland-Stack und mein WordPress-Setup haben auf den ersten Blick nix miteinander zu tun. Auf den zweiten Blick schon. Dieselbe Technologie, die mein Theme konfiguriert — theme.json —, authentifiziert Bürger am EUDI-Wallet per SD-JWT und validiert Behördenanträge in FIT-Connect per JSON Schema.
Diese Durchgängigkeit ist kein Zufall. JSON hat gewonnen, weil es einfach genug ist, um überall zu funktionieren, und strukturiert genug, um Maschinen gscheit miteinander reden zu lassen. Von der WordPress-Site bis zur digitalen Verwaltung eines ganzen Landes.
Ob der Deutschland-Stack seine Versprechen bis 2028 einlöst, steht auf einem anderen Blatt. Die OKF-Kritik ist berechtigt — Standards ohne Architektur sind eine Einkaufsliste ohne Rezept. Aber das Format, auf dem diese Zukunft aufbaut, ist solide. Es heißt JSON. Und es arbeitet schon längst — in jedem Webhook, jedem API-Call, jedem theme.json, das ich anfasse.