// stack · schnittstelle
OpenImmo ist der offene XML-Standard für den Austausch von Immobiliendaten: Die Makler-Software exportiert ihre Objekte als Datensatz, die Website liest ihn ein. Für siteway ist das der Weg, wie Objekte auf eine Website kommen, ohne dass jemand sie ein zweites Mal eintippt — mit Objektliste, Filtern, Detailseite und einer Löschlogik, die verkaufte Objekte nicht ins Leere laufen lässt.
// definition
OpenImmo ist ein offener Standard für den Austausch von Immobiliendaten im XML-Format — eine Datensatzbeschreibung, auf die sich Makler-Software, Portale und Websites geeinigt haben. Der tragende Verein stellt das selbst nüchtern klar: OpenImmo ist keine Software, kein Portal und keine Schnittstelle im technischen Sinn, sondern die Beschreibung eines Datensatzes. Wer die Datei überträgt und was der Empfänger daraus macht, regeln die beteiligten Systeme.
Getragen wird der Standard vom OpenImmo e.V., dem „Verein zur Förderung des Datenaustausches in der Immobilien-Wirtschaft“, der sich 2001 konstituiert hat und heute über dreißig Fördermitglieder zählt. Die Spezifikation liegt als XML-Schema in der 1.2.7er-Reihe vor — und weil sie ein Schema ist, lässt sich jede einzelne Lieferung maschinell prüfen, statt sie nur zu hoffen.
Der praktische Nutzen liegt in der Einmalpflege: Ein Objekt wird in der Makler-Software angelegt und beschickt von dort aus die Portale und die eigene Website. Genau deshalb bringen onOffice, FLOWFACT und Propstack einen OpenImmo-Export mit — und deshalb ist eine Website, die OpenImmo liest, nicht an einen Hersteller gebunden.
// praxis
export zuerst · mapping danach
Ein OpenImmo-Import ist ein Prozess, keine Datei. Am Anfang steht die Abholung: Der Importer sieht in festem Turnus im FTP-Verzeichnis nach, zieht neue ZIP-Pakete, entpackt sie in ein Arbeitsverzeichnis und prüft die XML gegen das Schema. Was nicht valide ist, wird nicht eingespielt, sondern protokolliert und gemeldet — ein halb importierter Bestand richtet mehr Schaden an als ein ausgefallener Lauf. Erst wenn eine Lieferung vollständig durchgeht, wird sie übernommen.
Danach kommt der Teil, der jedes Projekt unterscheidet: das Feld-Mapping.
Der Standard kennt weit mehr Felder, als ein einzelner Export tatsächlich füllt — deshalb
arbeiten wir am echten Export-Paket, nicht an der Spezifikation. Wir legen fest, welches
Element auf welches Feld im CMS läuft: objektkategorie auf
Objektart und Vermarktungsart, geo auf Adresse und
Koordinaten, preise,
flaechen und
ausstattung auf die Spec-Tabelle der Detailseite,
freitexte auf Titel, Objekt- und Lagebeschreibung. Die
Objektnummer aus verwaltung_techn ist der Schlüssel, an dem
ein Objekt über alle Lieferungen hinweg wiedererkannt wird — daran hängt, ob eine Änderung als
Änderung ankommt oder als Dublette.
Bilder und Dokumente stehen als anhang in der XML und liegen
als Datei im selben ZIP. Aus jedem Original erzeugen wir beim Import die Ableitungen, die das
Frontend wirklich braucht — AVIF und WebP
in mehreren Breiten, damit ein Exposé-Foto nicht als Mehr-Megabyte-JPEG in der Objektliste
landet. Die Löschlogik läuft über die Aktionsart: DELETE
nimmt das Objekt aus Liste und Filter, ein Vollabgleich setzt still, was in der Lieferung
fehlt. Jeder Lauf wird protokolliert, jeder Fehler gemeldet — und ausdrücklich auch der Fall,
dass gar nichts mehr ankommt.
Auf der Website wird daraus das, was Besucher sehen: eine Objektliste mit Filtern auf Vermarktungsart, Objektart, Ort, Preis und Fläche, Detailseiten mit Galerie und Spec-Tabelle, der Exposé-Download und ein Kontaktformular direkt am Objekt, das die Objektnummer gleich mitschickt. Die Suche greift auf denselben Datenstand zu, die strukturierten Daten ebenfalls. Gepflegt wird trotzdem weiterhin nur an einer Stelle — in der Makler-Software.
// bausteine · 6 details
vom paket bis zur detailseite
Der Standard beschreibt mehr, als ein Projekt je braucht. Das sind die Teile, an denen eine Anbindung tatsächlich hängt — und was wir mit ihnen machen.
// d-01transport
Die Makler-Software packt XML und Bilder in ein ZIP-Archiv und legt es per FTP im Zielverzeichnis ab — je Ziel mit eigenen Zugangsdaten. Der Importer holt ab, entpackt und arbeitet: Die Website zieht die Daten, statt auf einen Push zu warten.
zweck: übertragung
// d-02abgleich
Im Element uebertragung steht das Attribut umfang auf VOLL oder TEIL. VOLL bildet den kompletten aktiven Bestand ab, TEIL nur die Bewegungen. Ein Importer muss beide Fälle sauber trennen — sonst löscht der falsche Lauf den halben Bestand.
zweck: bestand halten
// d-03datensatz
Ein Objekt je immobilie: Objektkategorie, Geo-Daten, Preise, Flächen, Ausstattung, Zustandsangaben mit Baujahr und Energieausweis, Freitexte und Kontaktperson — dazu verwaltung_objekt und verwaltung_techn mit Objektnummer und Aktionsart.
zweck: objektdaten
// d-04medien
Jedes Bild und jedes Dokument steht als anhang mit Gruppe, Format und Pfad in der XML, die Datei selbst liegt im ZIP. Beim Import entstehen daraus die Ableitungen für Galerie, Liste und Vorschau — in den Breiten, die das Layout wirklich anfragt.
zweck: bilder ohne ballast
// d-05frontend
Aus dem Datenmodell wird die Objektliste mit Filtern auf Vermarktungsart, Objektart, Ort, Preis und Fläche, die Detailseite mit Galerie und Spec-Tabelle — dazu Exposé-Download und ein Kontaktformular am Objekt, das die Objektnummer mitschickt.
zweck: was besucher sehen
// d-06sichtbarkeit
Sprechende URLs aus Objektart, Ort und Objektnummer statt aus Zufallszahlen — dazu JSON-LD nach schema.org mit RealEstateListing, dem passenden Wohn-Typ und einem Offer. Verkaufte Objekte laufen über eine Weiterleitung, nicht in eine Fehlerseite.
zweck: auffindbar bleiben
// integration
ein importweg · drei systeme
Der Weg ist in jedem System derselbe, und er ist bewusst systemunabhängig gedacht: Ein Import-Job holt den Export ab, entpackt ihn, prüft die XML gegen das Schema und legt jedes Objekt als Inhalt im CMS an — neu, wenn die Objektnummer unbekannt ist, sonst als Aktualisierung des vorhandenen Datensatzes. Gebaut wird diese Anbindung von siteway, mit den Bordmitteln des jeweiligen Systems: als eigene Extension, als eigenes Plugin, als eigener Command im Framework. Das Frontend liest anschließend nur noch aus dem CMS und rendert daraus Objektliste, Filter und Detailseite. Unterschiedlich ist im Grunde nur, wie das jeweilige System „Inhalt“ nennt: Record, Custom Post Type oder Entry.
Zwei Dinge müssen dafür im CMS liegen. Erstens ein eigener Inhaltstyp mit einem Datenmodell, das die Felder aus dem Mapping trägt: Objekt- und Vermarktungsart, Preise, Flächen, Ausstattung, Freitexte, Geo-Daten — und die Objektnummer als Schlüssel, an dem ein Objekt über alle Lieferungen hinweg wiedererkannt wird. Zweitens ein Platz für die Anhänge in der Medienverwaltung des Systems, damit Bilder und Exposés dort liegen, wo das CMS sie auch verwaltet.
Alles Weitere übernimmt der Import: abholen, validieren, mappen, Objekte anlegen und aktualisieren, Bild-Ableitungen erzeugen, zurückgezogene Objekte stilllegen und jeden Lauf protokollieren. Die Redaktion tippt danach keine Objektdaten mehr ab — sie arbeitet auf ihnen weiter: Objekte hervorheben, Sortierungen setzen, redaktionelle Landingpages und Beschreibungstexte um den importierten Bestand herum bauen.
// i-01typo3
In TYPO3 bauen wir die Anbindung als eigene Extension auf Extbase. Das Datenmodell steht in der TCA: Objekt- und Vermarktungsart, Preise, Flächen, Ausstattung, Freitexte, Geo-Daten — und die Objektnummer als Schlüssel. Der Import läuft als Scheduler-Task im gesetzten Turnus und legt jedes Objekt als Record in einem Systemordner ab, dessen PID konfiguriert wird. Sprechende URLs kommen aus dem Site Handling, die Ausgabe von Fluid-Templates: Liste, Filter, Detailseite. Die Redaktion pflegt im Backend das, was über den Export hinausgeht.
// i-02wordpress
In WordPress liegt die Anbindung in einem eigenen Plugin statt im Theme-Code — sie überlebt damit jeden Theme-Wechsel. Die Objekte sind ein Custom Post Type mit eigenen Meta-Feldern für die Werte aus dem Mapping und Taxonomien für alles, wonach später gefiltert wird: Objektart, Vermarktungsart, Lage. Den Import stößt ein geplanter Lauf an, Bilder und Exposés landen in der Mediathek. Fürs Frontend liefert dasselbe Plugin Template und Blocks, damit Liste, Filter und Detailseite zum Datenmodell passen.
// i-03statamic
Statamic läuft auf Laravel — dort bauen wir die Anbindung: ein eigener Artisan-Command, den der Scheduler im gesetzten Turnus startet, holt das Paket, validiert es und schreibt die Objekte als Entries in eine Collection. Das Datenmodell steht als Blueprint, Bilder und Exposés liegen im Assets-Container. Antlers oder Blade rendern Liste, Filter und Detailseite, das Static Caching liefert sie als fertige Seiten aus. Feldnamen, Mapping und URL-Struktur bestimmen wir selbst.
// entscheidung
zuordnung statt rangliste
OpenImmo ist ein Transportweg, kein Selbstzweck. An drei Zeichen erkennen wir, dass er der richtige ist — darunter steht, wo ein anderer Weg schneller ans Ziel führt.
// e-01quelle
Wer Exposés, Preise und Fotos ohnehin in onOffice, FLOWFACT oder Propstack pflegt, will sie nicht ein zweites Mal ins CMS tippen. OpenImmo ist der Weg, der ohne Sonderabsprache zwischen den Herstellern funktioniert.
einmal pflegen
// e-02bewegung
Neue Objekte, geänderte Preise, Verkäufe: Wenn sich am Bestand laufend etwas ändert, ist der automatische Abgleich schnell günstiger als die Handpflege — und vor allem verlässlicher, weil niemand das Nachtragen vergisst.
immer aktuell
// e-03unabhängigkeit
Weil der Standard herstellerübergreifend ist, hängt die Website nicht an einem Anbieter. Ein Wechsel der Makler-Software heißt dann: ein neues Export-Ziel einrichten — und nicht die Objektwelt der Website neu bauen.
herstellerübergreifend
Etliche Makler-Systeme bieten neben dem OpenImmo-Export eine eigene REST-API. Wenn ein neues Objekt in Sekunden statt im nächsten Turnus online stehen soll, oder wenn Felder gebraucht werden, die der Standard nicht kennt — eigene Kategorien, interne Vermerke, Beziehungen zwischen Objekten und Projekten —, dann ist der direkte Weg über die API der passendere. Häufig laufen beide nebeneinander: OpenImmo trägt den Bestand, die API liefert das, was darüber hinausgeht.
Und wenn nicht Objektdaten, sondern Bewertungen und Marktzahlen auf die Website sollen, ist PriceHubble die passende Quelle — ein anderer Dienst mit einer anderen Logik. Welcher Weg dein Projekt trägt, klären wir im Konzept, bevor gebaut wird; gebaut, getestet und überwacht wird er dann als Schnittstellenentwicklung.
// faq
OpenImmo ist ein offener Standard für den Austausch von Immobiliendaten im XML-Format. Er beschreibt, wie ein Objekt-Datensatz aufgebaut ist: Objektart, Lage, Preise, Flächen, Ausstattung, Freitexte, Bilder und Dokumente. Getragen wird er vom OpenImmo e.V., dem Verein zur Förderung des Datenaustausches in der Immobilien-Wirtschaft, der sich 2001 konstituiert hat. Der Verein stellt dabei selbst klar: OpenImmo ist keine Software und kein Portal, sondern die Beschreibung eines Datensatzes. Wer die Daten überträgt und was der Empfänger daraus macht, regeln die beteiligten Systeme.
Die Makler-Software exportiert die Objekte als OpenImmo-XML und packt die Datei zusammen mit den Bildern in ein ZIP-Archiv. Dieses Archiv landet per FTP in einem Zielverzeichnis, für das jedes Ziel eigene Zugangsdaten bekommt. Auf der Website-Seite holt ein Importer die Pakete in festem Turnus ab, entpackt sie, prüft die XML gegen das Schema und schreibt die Daten in das Datenmodell des CMS. Erst danach entstehen daraus Objektliste, Filter und Detailseite. Gepflegt werden die Objekte weiterhin nur an einer Stelle, nämlich in der Makler-Software.
Der Vollabgleich überträgt den kompletten aktiven Bestand: Was in der Lieferung fehlt, gilt als nicht mehr aktiv. Der Teilabgleich überträgt nur die Bewegungen, also neue und geänderte Objekte mit der Aktionsart CHANGE und zurückgezogene mit DELETE. Welcher Fall vorliegt, steht im Kopf der Datei im Element uebertragung, im Attribut umfang mit den Werten VOLL und TEIL. Wir legen den Importer so aus, dass er beides beherrscht: Der Teilabgleich ist der Normalbetrieb, der Vollabgleich der Erstimport und die Notbremse, wenn Bestand und Website auseinanderlaufen.
Ein verkauftes Objekt verschwindet aus der Lieferung oder kommt mit der Aktionsart DELETE. Daraus darf keine tote URL werden. Wir lösen das in drei Stufen: Das Objekt fällt sofort aus Liste und Filter, die Detailseite bleibt für eine vereinbarte Frist mit klarer Statusangabe als Referenz bestehen, danach leitet die URL dauerhaft auf die passende Objektliste weiter. So bleibt ein bestehender Suchmaschinen-Eintrag verwertbar, und wer über einen alten Link kommt, landet bei Vergleichbarem statt auf einer Fehlerseite.
Verbreitete Systeme wie onOffice, FLOWFACT und Propstack bringen einen OpenImmo-Export mit, ebenso viele kleinere Programme. Genau das ist der Sinn eines Standards: Der Weg auf die Website hängt nicht am Hersteller, und ein Wechsel der Makler-Software zwingt dich nicht zum Umbau der Website. Vor dem Bauen sehen wir uns trotzdem ein echtes Export-Paket an, denn der Standard erlaubt deutlich mehr Felder, als ein einzelner Export tatsächlich füllt.
Das bestimmt der Turnus, in dem der Importer nachsieht, von mehrmals täglich bis stündlich. Schneller als die Quelle exportiert, wird die Website allerdings nicht aktuell, deshalb stimmen wir Turnus und Export-Zeitplan aufeinander ab. Jeder Lauf wird mit Zeitstempel, Zahl der verarbeiteten Objekte und aufgetretenen Fehlern protokolliert. Und wir überwachen auch den Stillstand: Kommt über einen definierten Zeitraum kein Paket an, geht eine Meldung raus, statt dass ein veralteter Bestand still weiterläuft.
Ja, in allen drei Systemen — der Weg unterscheidet sich nur im Detail, denn wir bauen die Anbindung jeweils mit den Bordmitteln des Systems. In WordPress liegt sie in einem eigenen Plugin: Custom Post Type mit eigenen Meta-Feldern, Taxonomien für die Filter, ein geplanter Lauf für den Import, Template und Blocks fürs Frontend. In TYPO3 ist es eine eigene Extension: TCA als Datenmodell, Import als Scheduler-Task, Objekte als Records in einem Systemordner, Site Handling für sprechende URLs, Fluid für die Ausgabe. In Statamic bauen wir im Laravel-Unterbau: Ein Artisan-Command im Scheduler schreibt die Objekte als Entries in eine Collection und die Bilder in den Assets-Container, Antlers oder Blade rendern das Frontend. Feld-Mapping und Abgleichlogik bleiben überall dieselben.
Ja. Diese Seite beschreibt die Technik dahinter: Datensatz, Übertragung, Abgleichlogik und den Weg ins CMS. Die buchbare Leistung mit Feld-Mapping, Entwicklung, Test auf Staging, Go-live und Monitoring beschreibt siteway unter Schnittstellenentwicklung in der Expertise. Was auf der Website daraus wird, also Objektliste mit Filtern, Detailseite, Exposé-Download und Kontaktformular am Objekt, klären wir vorher im Konzept.
// womit das zusammenhängt
leistung, sichtbarkeit & redaktion
// leistung · buchen
Die Technik hier, das Angebot dort: Scoping, Feld-Mapping, Entwicklung, Test auf Staging, Go-live und Monitoring. Hier wird gebucht.
zur leistung →
// stack · sichtbarkeit
Importierte Objektdaten sind schon strukturiert — als JSON-LD ausgezeichnet, versteht sie auch die Suchmaschine statt nur der Besucher.
zur technik →
// stack · kategorie
Wohin die Objekte importiert werden: TYPO3, WordPress oder Statamic — und nach welchen Kriterien wir zwischen ihnen wählen.
zum hub →
// Objekte automatisch auf der Website?
Projekt anfragen