Eine Hausverwaltung sitzt selten allein am Tisch. Die Steuerkanzlei bucht in DATEV, der Messdienstleister liest Heizkostenverteiler über eigene Portale aus, der Schlüsseldienst verwaltet Zutrittsrechte in einem Cloud-System des Smart-Lock-Herstellers, der Handwerker arbeitet in einem Ticket-System der Genossenschaft, und die institutionellen Eigentümer erwarten Reportings in ihrem Asset-Management-Tool. Wer als Software-Anbieter für Hausverwaltungen glaubt, dieses Umfeld durch ein noch etwas breiter gezogenes Produkt ersetzen zu können, überschätzt die eigene Reichweite und unterschätzt die Wechselkosten. Die realistische Antwort ist nicht „alles in einem”, sondern: offene Schnittstellen zu den Werkzeugen, die bereits im Einsatz sind.
Genau das ist der Kern des Epic #134 in ImmoGenio: eine systematische Öffnung der Software nach außen. DATEVconnect online für den direkten Export an die Steuerkanzlei. Eine Provider-Abstraktion für Messdienstleister, damit Zählerstände von Techem und ista in die Heizkostenabrechnung fließen, ohne dass jemand sie abtippt. Eine Integration mit Tapkey, damit zeitgebundene digitale Schlüssel zu Handwerkereinsätzen und Wohnungsübergaben gehören statt zum Schlüsselkasten im Hausmeisterbüro. Und eine Public Partner-API, über die Dritt-Tools kontrolliert lesende Zugriffe erhalten — mit feingranularen Scopes, Rate-Limiting und signierten Webhooks.
Der Standard für die Steuerkanzlei: DATEVconnect online statt CSV-Import
Der DATEV-Export ist in ImmoGenio seit mehreren Migrationsrunden produktiv: CSV im Format 7.0, 29-Feld-Header, CP1252-Encoding, CRLF-Zeilenenden, als ZIP-Bundle inklusive PDF-Belegen. Ein Steuerberater kann diese Datei in DATEV Rechnungswesen oder DATEV Unternehmen online importieren und erhält einen buchungsfertigen Stapel. Was bis heute fehlt, ist der letzte Meter: die Datei muss manuell heruntergeladen, per E-Mail verschickt oder über ein Kanzleiportal hochgeladen werden.
DATEVconnect online ist die Programmierschnittstelle, über die autorisierte Drittanwendungen Buchungsstapel und Belege direkt in den DATEV-Bestand eines Mandanten übertragen. Der Zugriff erfolgt über OAuth 2.0 nach RFC 6749 mit Authorization-Code-Flow und kurzlebigen Access-Tokens. Die Autorisierung geschieht einmal durch den Steuerberater in seiner DATEV-Umgebung; anschließend genügt in ImmoGenio ein Klick, damit der bereits validierte Stapel samt Belegen in der Kanzlei landet. Der bestehende CSV-Generator bleibt unverändert — DATEVconnect ist eine zusätzliche Übertragungsschicht, kein Ersatz.
Der Gewinn liegt nicht primär in der gesparten Minute für den Upload, sondern in drei anderen Effekten. Erstens: keine Version-Drift mehr zwischen dem, was die Verwaltung exportiert, und dem, was in der Kanzlei importiert wird — der Stapel wird idempotent mit einer Export-UUID übertragen und kann bei Unklarheiten reproduzierbar identifiziert werden. Zweitens: Belege kommen mit, im selben API-Call, ohne dass sie in einer getrennten E-Mail verschickt werden müssten. Drittens: auditfähige Historie auf beiden Seiten — in ImmoGenio ist jeder Upload im audit_log protokolliert, in DATEV landet er im Eingangsordner des Mandanten mit Zeitstempel und API-Client-Identifikation.
Messdienstleister-Fernauslese: Weg von der manuellen Zählerstand-Erfassung
Seit dem 1. Dezember 2021 dürfen nach § 5 HeizkostenV Abs. 2 (in der durch die EED-Umsetzung 2021 geänderten Fassung) nur noch fernauslesbare Zähler neu installiert werden. Bis zum 31. Dezember 2026 müssen bestehende Zähler fernauslesbar nachgerüstet oder ausgetauscht sein. Die Mehrheit der deutschen Wohngebäude wird damit in wenigen Monaten mit Zählern ausgestattet sein, die ihre Stände automatisch an den Messdienstleister übertragen — und die Hausverwaltung steht vor der Frage, wie diese Daten in ihre Abrechnungssoftware gelangen.
Drei Wege sind heute üblich. Erstens: Der Messdienstleister schickt eine PDF-Abrechnung, die Verwaltung bucht die Summe. Das ist arbeitssparend, aber der Verwalter gibt die Kontrolle über die Einzelumlage ab. Zweitens: Der Messdienstleister liefert eine Excel-Tabelle mit Zählerständen, die Verwaltung kopiert sie manuell in die Abrechnungssoftware. Das ist fehleranfällig und nicht audit-sicher. Drittens: Eine direkte API-Integration, die Zählerstände automatisiert, nach Einheit und Zeitraum strukturiert, in die Software überträgt.
ImmoGenio setzt auf den dritten Weg — allerdings über eine Provider-Abstraktion. Das Interface IMeteringProvider definiert ein einheitliches Datenmodell (Einheit, Zähler-ID, Zeitstempel, Stand, Einheit, Medium) und wird von austauschbaren Implementierungen erfüllt. Der MVP umfasst zwei Provider: einen Techem-XML-Parser für den etablierten Austauschstandard der Techem GmbH und einen ista-Webservice-Adapter für die REST-basierte Schnittstelle der ista Deutschland GmbH. Die Abbildung erfolgt auf die bestehende Tabelle nk_zaehlerstaende, auf der bereits die Heizkostenabrechnung nach § 6b HeizkostenV aufsetzt. Minol und Kalorimeta sind im Interface vorbereitet, aber nicht Teil des MVP — die Priorisierung folgt der Marktverteilung und dem dokumentierten Verhalten der jeweiligen Ausgabeformate, nicht der Werbung der Hersteller.
Die Provider-Abstraktion ist bewusst kein technisches Spielzeug. Sie schützt vor einem realen Risiko: Messdienstleister ändern ihre Ausgabeformate regelmäßig, sie werden übernommen, sie führen neue Authentifizierungsverfahren ein. Eine Software, die einen einzelnen Provider hart verdrahtet, verliert mit jedem dieser Ereignisse Funktionalität. Eine Software, die auf einem stabilen internen Datenmodell arbeitet und Provider-spezifischen Code in austauschbaren Adaptern kapselt, übersteht diese Veränderungen mit punktuellem Eingriff.
Smart-Lock am Beispiel Tapkey: Zeitgebundene Schlüssel statt Briefumschläge
Wer heute einen Handwerker beauftragt, ohne dass ein Hausmeister vor Ort ist, steht vor einer Wahl: einen physischen Schlüssel übergeben und hoffen, dass er zurückkommt, oder einen Schlüsselkasten mit Zahlencode betreiben und den Code rotieren. Beide Wege sind operativ aufwendig und sicherheitstechnisch mindestens diskutabel. Smart-Locks mit digitaler Schlüsselvergabe lösen das Problem an der richtigen Stelle, nämlich am Schließzylinder.
Tapkey ist einer der etablierten Anbieter im deutschsprachigen Raum: Schließzylinder mit Bluetooth-LE-Schnittstelle, eine App, die Zugänge erteilt und entzieht, eine Cloud-Verwaltung mit API. ImmoGenio integriert diese API über das Interface ILockProvider — und bindet die digitale Schlüsselvergabe kontextbezogen an die bereits bestehenden Prozesse der Verwaltung. Ein zeitgebundener Schlüssel für einen Handwerker ist kein separates Dokument, sondern Teil einer Task im Task-Management (Kapitel 5.2 der Feature-Dokumentation): erstellt beim Beauftragen, aktiv im Zeitfenster der Terminplanung, automatisch widerrufen beim Status-Wechsel auf „erledigt”. Ein Zugangscode für eine Wohnungsübergabe (Kapitel 7.1) endet mit der Signatur des Protokolls.
Die Implementierung hält das Interface bewusst offen für weitere Anbieter — Nuki, KIWI, iLoq. Welcher Anbieter produktiv unterstützt wird, folgt der Nachfrage der Mandanten und der Verfügbarkeit dokumentierter APIs mit belastbarer Uptime-Zusage. Der Provider-Wechsel bleibt eine Implementierungs-Entscheidung, keine Schema-Migration.
Rechtlich ist die digitale Schlüsselvergabe unproblematisch, solange zwei Bedingungen erfüllt sind. Erstens: Der Vermieter bzw. Verwalter hat ein berechtigtes Interesse im Sinne von § 535 BGB und Art. 6 Abs. 1 lit. f DSGVO, den Zugang zu verwalten — bei Wohnraumkontext mit der Einschränkung, dass der Mieter nach § 535 Abs. 1 BGB den ungestörten Gebrauch der Wohnung erhält. Eine Fernöffnung durch den Verwalter ohne konkreten Anlass ist nicht gedeckt. Zweitens: Protokollierung der Zugriffe, damit im Streitfall nachvollziehbar ist, wer wann Zugang hatte. Beides ist Teil des Integrations-Designs.
Public Partner-API: Öffnen, ohne die Kontrolle abzugeben
Die drei vorgenannten Integrationen sind produktspezifisch: ImmoGenio bindet DATEV, Techem, ista und Tapkey an. Der Ecosystem-Ansatz ist damit nicht abgeschlossen. Er wird ergänzt um eine Public Partner-API — eine dokumentierte, versionsgepflegte Schnittstelle, über die beliebige Drittsysteme lesend auf definierte Ressourcen zugreifen können, nach ausdrücklicher Freigabe durch den jeweiligen Mandanten.
Der technische Rahmen orientiert sich an etablierten Standards: OpenAPI 3.0 als Spezifikationsformat, OAuth-2.0-ähnliche API-Tokens mit feingranularen Scopes im Format Resource:Action analog zum bestehenden RBAC-Modell, Rate-Limiting auf Token-Ebene gegen Missbrauch und versehentliche Selbst-DoS-Angriffe, Webhooks mit HMAC-SHA-256-Signatur nach RFC 2104 für ereignisgetriebene Benachrichtigungen, ausschließlich TLS-verschlüsselte Verbindungen. Die v1 der Partner-API umfasst bewusst nur lesende Endpunkte für fünf Kernressourcen: Objekte, Einheiten, Mietverträge, Belege, Audit-Events. Schreibende Zugriffe bleiben dem internen Portal vorbehalten, bis die Validierungs- und Autorisierungsflüsse für externe Schreibzugriffe vollständig spezifiziert sind.
Zwei Aspekte sind dabei nicht verhandelbar. Zum einen die Mandantentrennung: Jedes API-Token ist genau einem Tenant zugeordnet, jede Anfrage wird über die bestehende Row-Level-Security-Schicht der PostgreSQL-Datenbank geführt, ein Token-Leak kann damit maximal Daten eines einzelnen Mandanten exponieren — keinen Querschnitt über alle. Zum anderen der Auftragsverarbeitungs-Vertrag nach Art. 28 DSGVO: Vor der ersten Connection eines Dritt-Tools muss eine dokumentierte Auftragsverarbeitungs-Vereinbarung zwischen dem Mandanten und dem Anbieter des Dritt-Tools vorliegen, die im System als Connection-Voraussetzung hinterlegt wird (dpa_accepted_at-Feld in der Tabelle partner_connections). Ohne diese Zusicherung kann keine Verbindung aufgebaut werden.
Sicherheit: Was bei offenen Schnittstellen unverhandelbar ist
Wer Schnittstellen öffnet, öffnet auch Angriffsflächen. Die Architektur trägt dem in sechs Punkten Rechnung.
Erstens: Token-Verschlüsselung at rest. OAuth-Tokens für ausgehende Verbindungen (etwa zu DATEVconnect) werden mit pgcrypto in der Datenbank verschlüsselt, der Schlüssel liegt ausschließlich in der Laufzeitumgebung der API und wird über SOPS mit age-Verschlüsselung aus einem verschlüsselten Secret-Store geladen. Ausgehende API-Tokens für Partner werden nur als SHA-256-Hash gespeichert — das generierte Token ist im Klartext nur einmal bei der Erstellung sichtbar und kann nicht wiederhergestellt werden.
Zweitens: Webhook-Signaturen. Jeder eingehende Webhook wird mit einem HMAC-SHA-256 über den Request-Body und einem partner-spezifischen Secret signiert. Die Validierung erfolgt vor jeder Verarbeitung; nicht-signierte oder falsch signierte Requests werden ohne Weiterleitung verworfen. Ein Replay-Schutz wird über einen kombinierten Nonce + Zeitstempel implementiert, ältere Requests werden abgelehnt.
Drittens: Idempotenz. Jede Synchronisations-Operation trägt eine eindeutige event_id. Mehrfach-Zustellung durch Netz- oder Partner-seitige Retries führt zu genau einer Anwendung im System.
Viertens: Rate-Limiting. Pro API-Token ein konfigurierbares Fenster mit Redis-basiertem Sliding-Window-Counter. Überschreitung führt zu HTTP 429, das Limit wird im X-RateLimit-*-Header kommuniziert.
Fünftens: Audit-Trail. Jeder externe Zugriff, jede ausgehende Synchronisation, jede Token-Erstellung und jeder OAuth-Connect landet im audit_log. Die zeitliche und inhaltliche Nachvollziehbarkeit ist nicht optional, sie ist die Grundlage für DSGVO-Auskünfte nach Art. 15 und für Prüfpflichten gegenüber dem Finanzamt.
Sechstens: Provider-Fallback. Eine Integration, deren Gegenstelle nicht verfügbar ist, darf das interne Portal nicht blockieren. Alle Provider-Adapter laufen in einem Timeout-gekapselten, asynchronen Kontext; ein Ausfall von DATEV, Techem oder Tapkey führt zu einem dokumentierten Fehlerzustand der betreffenden Operation, nicht zu einer hängenden Portal-Oberfläche.
Was dieser Ansatz bewusst nicht ist
Eine ehrliche Abgrenzung gehört dazu, sonst entsteht die Erwartung an ein Universal-Ecosystem, das niemand liefern kann.
Die Partner-API ist in v1 ausschließlich lesend. Es gibt keine Schreib-Endpunkte, keine externe Buchungserstellung, keine externe Mieter-Anlage. Wer Schreibzugriff über Drittsysteme benötigt, arbeitet weiterhin über das interne Portal oder die etablierten Provider-Integrationen.
Es gibt keinen Partner-Marketplace. Dritt-Tools werden nicht beworben, nicht zertifiziert, nicht in einem Katalog gelistet. Die Verantwortung für die Auswahl eines Drittanbieters bleibt beim Mandanten; ImmoGenio stellt die Schnittstelle, nicht die Empfehlung.
Es gibt keine Abrechnung für API-Nutzung in v1. Rate-Limits sind ein Schutz vor Missbrauch, kein Preismodell. Wenn sich das ändert, wird es transparent über das Pricing-Modell (Epic #108) kommuniziert.
Es gibt keine direkte M-Bus- oder LoRa-Integration auf Geräteebene. Die Kommunikation mit den Zählern bleibt beim Messdienstleister; ImmoGenio konsumiert das Ergebnis über die API des Dienstleisters, nicht über das Funkprotokoll am Zähler.
Und es gibt in v1 keine Minol- oder Kalorimeta-Produktivintegration. Die Provider-Abstraktion ist vorbereitet, die konkreten Adapter werden nach dokumentierter Mandanten-Nachfrage und verfügbarer Spezifikation ergänzt.
Wo wir stehen
Das Epic ist beschlossen, die Architektur dokumentiert, die Sub-Issues geschnitten: Schema für Partner-Connections mit verschlüsselten OAuth-Tokens, DATEVconnect-Adapter auf Basis des bestehenden CSV-Generators, IMeteringProvider mit Techem- und ista-Implementierung, ILockProvider mit Tapkey-Adapter, Public Partner-API mit fünf Read-Endpunkten und eigenem OpenAPI-Tag, eine Admin-Oberfläche unter /integrationen für Connection-Verwaltung, Token-Editor mit Scope-Auswahl und Webhook-Log, eine Smart-Lock-Inline-Bedienung in den Übergabe- und Task-Flows, sowie eine eigenständige Security-Review als Abschluss.
Der Kern des Ansatzes ist keine Technologie-Wahl, sondern eine Haltung: Hausverwaltungs-Software muss mit der Welt ihrer Kunden umgehen können, nicht umgekehrt. Die Steuerkanzlei bucht in DATEV — dann geht ImmoGenio zu DATEV. Der Messdienstleister liefert Zählerstände über seine API — dann konsumiert ImmoGenio diese API. Der Handwerker bekommt einen Tapkey-Zugang — dann erteilt ImmoGenio diesen Zugang zeitgebunden. Und wenn ein Verwalter ein Reporting-Werkzeug eines Drittanbieters einsetzen möchte, stellt ImmoGenio die Schnittstelle dafür bereit, scoped, rate-limited und auditierbar.
Was bleibt, ist die Datenhoheit beim Mandanten. Was geht, sind die Brüche zwischen den Werkzeugen.
Fragen, Rückmeldungen oder konkrete Integrations-Wünsche an weitere Provider? Wir freuen uns über Ihre Nachricht an kontakt@immogenio.de.