Für Entwickler:innen

Schnittstellen

• REST: beschrieben mit OpenAPI 3.1, versioniert unter /v1. Das Format wählst du per Accept: JSON, JSON-LD oder für Messwerte CSV.
• GraphQL: für gezielte Abfragen über mehrere Objekttypen, mit Grenzen für Tiefe und Komplexität.
• JSON-LD: Datenmodell nach schema.org und ODTA, jede Antwort gegen JSON Schema und SHACL geprüft.
• Feeds und DCAT: alle offenen, freigegebenen Datensätze als JSON-LD-Feed je Typ, dazu ein DCAT-Katalog für Open-Data-Portale.
• Webhooks: Benachrichtigung bei Änderungen statt ständigem Abfragen, signiert mit HMAC-SHA256.
• Suche: hybride Suche nach Bedeutung und Stichwort unter /v1/search.
• Widgets: Web Components wie <hub-event-list>, <hub-detail> und <hub-map> für jede Website, ohne Framework, von deinem eigenen Server.
• MCP: ein Model-Context-Protocol-Server, über den KI-Agenten mit denselben Rechten wie dein API-Key lesen, mit Herkunft und Lizenz in jeder Antwort.

Herkunft und Lizenz in jeder Antwort

Jeder Datensatz trägt meta mit Quelle, Abrufzeit, Lizenz und Namensnennung. Du weißt also immer, was du wie weitergeben darfst.

Verträge zuerst

Datenmodell und Schnittstellen werden als Verträge festgelegt, bevor Code entsteht. Änderungen daran sind dokumentiert, versioniert und in der CI geprüft.

Connectoren

Jede Datenquelle ist ein eigener Container nach dem Airbyte-Protokoll. Im Code liegen Connectoren für feratel DS-API und DSI, contwise, Outdooractive, GeoSphere Austria, destination.one, ODTA-JSON-LD-Feeds, iCal und CSV. GeoSphere Austria, ODTA-Feeds, iCal und CSV sind mit Testdaten geprüft, die übrigen warten auf den Quellzugang. Eigene Connectoren baust du nach demselben Muster.

API-Dokumentation und Repository

Die API-Dokumentation und das öffentliche Repository verlinken wir hier, sobald die Veröffentlichung freigegeben ist.