// stack · schnittstelle
onOffice ist eine webbasierte Makler-Software aus Aachen: Objekte, Kontakte, Aufgaben und Vermarktung in einem System. Damit die Immobilien auch auf der eigenen Website stehen, gibt es zwei dokumentierte Wege — den OpenImmo-Export als Datenpaket und die onOffice-API als signierte Abfrage. Diese Seite beschreibt, wie siteway beide Wege baut und wann welcher trägt.
// definition
onOffice ist eine webbasierte Software für Immobilienmakler — ein CRM, das Objekte, Kontakte und Vermarktung in einem System zusammenführt. Entwickelt wird sie von der onOffice GmbH aus Aachen, die seit 2001 am Markt ist; nach Herstellerangaben arbeiten über 40.000 Nutzer damit. Das Kernprodukt heißt onOffice enterprise und läuft im Browser, ergänzt um eine App für den Außendienst.
Im Alltag eines Maklerbüros hängt daran fast alles: Immobilien mit Merkmalen, Preisen, Lage, Bildern und Grundrissen; Eigentümer und Interessenten als Adressdatensätze; Aufgaben, Termine und Besichtigungen; Exposés und der Versand an Immobilienportale. Wer ein Objekt anlegt, pflegt es genau einmal — und erwartet zu Recht, dass es überall auftaucht, wo es hingehört.
Genau da beginnt die Website. Sie ist keine zweite Datenpflege, sondern ein weiterer Kanal des Bestands. onOffice bietet dafür zwei dokumentierte Ausgänge: den Export im Branchenformat OpenImmo und eine HTTP-API mit Zugriff auf Objekte, Adressen und Bilder. Welcher Weg gebaut wird, entscheidet sich nicht am Geschmack, sondern an dem, was die Website können soll.
// praxis
mapping zuerst · technik danach
Wir fangen nicht beim Abruf an, sondern beim Feld-Mapping. Ein Objekt in onOffice hat weit mehr Felder, als eine Website je zeigen sollte — und die Website braucht Strukturen, die onOffice so nicht kennt. Deshalb legen wir zuerst fest, welches Quellfeld auf welches Feld im CMS-Datenmodell geht, welche Merkmale zu Filtern werden, wie Preise, Flächen und Energiewerte formatiert erscheinen und was passiert, wenn ein Feld leer ist. Diese Tabelle ist das eigentliche Bauwerk; alles danach ist Handwerk.
Danach kommt der Transport. Beim OpenImmo-Weg nimmt ein Import das abgelegte ZIP-Paket entgegen, entpackt XML und Bilder und schreibt die Objekte ins CMS. Beim API-Weg fragt ein geplanter Lauf die Objekte ab — und zwar nicht bei jedem Seitenaufruf, sondern in festem Takt in einen Cache. Ausgeliefert wird aus dem eigenen Bestand. Das hält die Seiten schnell, schont das Anfrage-Kontingent und sorgt dafür, dass die Website steht, auch wenn das CRM gerade nicht antwortet. Bilder ziehen wir einmal, legen sie lokal ab und liefern sie als AVIF und WebP in passenden Größen aus — Hotlinking auf fremde Bildserver ist weder schnell noch verlässlich.
Auf der Website entsteht daraus das, was Interessenten tatsächlich benutzen: eine Objektliste mit Filtern nach Art, Ort, Preis, Fläche und Zimmern, eine Detailseite mit Galerie, Beschreibung, Ausstattung, Energieangaben und Karte, ein Anfrageformular am Objekt, das die Objektnummer gleich mitschickt — und auf Wunsch ein Rückkanal, der die Anfrage als Adressdatensatz im CRM anlegt, statt sie in einem Postfach versanden zu lassen. Wie wir Formularstrecken bauen, steht in der Expertise zu Formularen.
Der Betrieb entscheidet, ob die Anbindung hält. Jeder Lauf wird protokolliert, Fehler laufen in eine Benachrichtigung statt in eine leere Seite, und ein abgebrochener Import überschreibt nie den vorhandenen Bestand — im Zweifel bleibt der letzte gute Stand stehen. Verkaufte und reservierte Objekte werden als solche gekennzeichnet, entfallene Objekte bekommen eine dauerhafte Weiterleitung auf die passende Liste, damit weder Besucher noch Suchmaschinen ins Leere laufen. Objektseiten bekommen zudem sprechende Adressen und strukturierte Daten, damit die Angebote in der Suche als das erscheinen, was sie sind.
Und weil an einer Makler-Website nicht nur Sachdaten hängen: Objektdaten sind Sachdaten, Anfragen sind personenbezogene Daten. Wir erheben im Formular nur, was für die Antwort nötig ist, übertragen verschlüsselt, geben Zugangsdaten nie ins Frontend und regeln die Auftragsverarbeitung schriftlich. Was das für Hosting, Header und Tracking bedeutet, steht im Stack unter Sicherheit & Datenschutz.
// bausteine · 6 details
belegt aus der hersteller-doku
Was in der Dokumentation von onOffice und des OpenImmo-Standards steht — und was davon in einer Website-Anbindung tatsächlich zum Tragen kommt.
// d-01export
OpenImmo ist der XML-Standard des gleichnamigen Vereins, der seit 2001 den Datenaustausch in der Immobilienwirtschaft regelt. Übertragen wird ein ZIP-Paket mit der XML-Datei und den Anhängen. In onOffice wird der eigene Webserver dafür als freie Portalschnittstelle eingerichtet.
zweck: bestand als paket
// d-02transport
Die Zugangsdaten des Webservers werden in den Portaleinstellungen hinterlegt, onOffice prüft die Verbindung direkt beim Speichern. Laut Doku werden SFTP und unverschlüsseltes FTP unterstützt, FTP mit TLS nicht — für uns heißt das: SFTP, und ein Konto, das nur in sein Eingangsverzeichnis darf.
zweck: zustellung auf den server
// d-03zugang
Die API ist ein kostenpflichtiges Zusatzmodul. Der Makler legt einen API-Benutzer an, dabei entstehen ein Token mit 32 und ein Secret mit 64 Zeichen. Jeder Aufruf geht als POST an api.onoffice.de und trägt Zeitstempel und HMAC — der Zeitstempel gilt nur rund zwei Minuten, die Uhr des Servers muss also stimmen.
zweck: signierte abfrage
// d-04objekte
Objekte liest die API über den Ressourcentyp estate. Im Aufruf steht, welche Felder kommen sollen — etwa Objekttitel, Kaufpreis oder Lage — dazu Filter mit den üblichen Operatoren, Sortierung und eine Umkreissuche über Postleitzahl oder Koordinaten. Fertige Filter aus der onOffice-Verwaltung lassen sich per Kennung übernehmen.
zweck: gezielt statt alles
// d-05mengen
Lesende Aufrufe liefern höchstens 500 Datensätze je Anfrage, voreingestellt sind 20. Für große Bestände empfiehlt die Doku, statt eines wachsenden Versatzes über die zuletzt gelesene Kennung weiterzublättern. Für Folgeläufe holen wir nur Geändertes über die Änderungsfelder von Objekten und Adressen.
zweck: kurze läufe
// d-06bilder & rückkanal
Für Bilder gibt es einen eigenen Aufruf, der die auf der Homepage freigegebenen Objektbilder liefert — mit Kategorie, Größe und Veröffentlichungsstatus. In die andere Richtung legt die API Adressen an; eine Dublettenprüfung über die E-Mail-Adresse verhindert, dass aus jeder Anfrage ein neuer Kontakt wird.
zweck: galerie · leads ins crm
// integration · 3 systeme
drei systeme · ein muster
Die Frage nach der onOffice Integration hat eine Antwort, die vor jedem System gilt: Ein Import- oder API-Job holt die Objekte, legt sie als ganz normale Inhalte im CMS an, und das Frontend rendert daraus Objektliste und Detailseite. Damit das trägt, braucht das CMS ein eigenes Datenmodell — Objektnummer, Vermarktungsart, Preis, Fläche, Zimmer, Lage, Energiewerte, Beschreibungstexte, Bilder als Medien und Merkmale als filterbare Werte. Die Objektnummer aus onOffice liegt darin als Schlüssel, damit ein Objekt bei jedem Lauf wiedergefunden und fortgeschrieben wird, statt ein zweites Mal zu entstehen.
Den Rest übernimmt der Cache: Ausgeliefert wird aus dem CMS-Bestand, nicht aus einer Live-Abfrage — das hält die Seiten schnell und lässt die Website auch dann stehen, wenn das CRM gerade nicht antwortet. Der Rückkanal setzt am Formular der Objektseite an: Es schickt die Objektnummer mit, und die Anfrage geht über die API als Adressdatensatz zurück ins CRM. Die Anbindung selbst ist unsere Arbeit: Wir bauen sie als eigenes Bauteil im jeweiligen System — mit dessen Bordmitteln, vom Datenmodell über den geplanten Lauf bis zur Ausgabe im Frontend. Welches CMS darunter liegt, ändert die Werkzeuge — nicht die Reihenfolge.
// i-01typo3
In TYPO3 docken beide Wege über eine eigene Extension an, die wir für das Projekt bauen. Das Datenmodell entsteht als TCA-Definition mit der Objektnummer als Schlüssel, die Objekte liegen als Records in einem eigenen Systemordner. Der Abgleich läuft als Scheduler-Task: Er liest das abgelegte OpenImmo-Paket ein oder holt die Objekte über die API — je nachdem, welcher Weg für das Projekt gesetzt ist. Extbase führt die Daten an die Ausgabe, Fluid-Templates rendern Liste und Detailseite, das Site Handling sorgt für sprechende URLs. Die Redaktion arbeitet danach im gewohnten Backend weiter und ergänzt Texte, Ansprechpartner und Einstiegsseiten rund um den Bestand.
// i-02wordpress
In WordPress liegt die Anbindung in einem eigenen Plugin, nicht im Theme — so übersteht sie jeden Designwechsel. Die Objekte entstehen als Custom Post Type mit eigenen Meta-Feldern; Vermarktungsart, Lage und Ausstattungsmerkmale kommen als Taxonomien dazu und tragen später die Filter. Ein geplanter Lauf übernimmt den Abgleich: Er verarbeitet das OpenImmo-Paket oder ruft die API ab — letzteres über eine eigene REST-Route auf dem Server, damit Token und Secret nie ins Frontend gelangen. Die Ausgabe übernehmen eigene Templates und Blocks, während die Redaktion Inhalte wie gewohnt im Editor pflegt.
// i-03statamic
Statamic läuft auf Laravel — die Anbindung ist damit reguläre Laravel-Arbeit und genau der Weg, den dieses System vorsieht. Ein Artisan-Command, den wir schreiben, liest das OpenImmo-Paket ein oder fragt die API ab; der Scheduler startet ihn im festen Takt. Die Objekte landen als Entries in einer eigenen Collection, deren Blueprint das Feld-Mapping eins zu eins abbildet. Bilder werden einmal gezogen und im Assets-Container abgelegt, das Frontend rendert Liste und Detailseite über Antlers oder Blade, das Static Caching liefert sie als fertige Seiten aus. Die Redaktion sieht danach normale Einträge im Control Panel: Texte ergänzen, Reihenfolge setzen, Objekte hervorheben — ohne dass der nächste Lauf die Arbeit überschreibt.
// entscheidung
zuordnung statt rangliste
Beide Wege sind vom Hersteller vorgesehen, beide funktionieren. Die Frage ist nicht, welcher moderner ist, sondern was die Website mit den Daten anstellen soll. Drei Muster, an denen wir das im Konzept festmachen.
// e-01export
Die Website soll den Bestand zeigen, mit Liste, Filtern, Detailseite und Anfrageformular. Der Turnus einer Übertragung reicht völlig. Dann ist der OpenImmo-Weg der richtige: weniger bewegliche Teile, kein Zusatzmodul, und weil das Format ein Standard ist, überlebt die Website auch einen Wechsel der Makler-Software.
robust & portabel
// e-02api
Sobald Daten in beide Richtungen laufen sollen — Anfragen als Kontakt ins CRM, Suchprofile, ein geschützter Bereich für Eigentümer — oder wenn die Website gezielt abfragen muss, was der Export gar nicht mitliefert. Auch Umkreissuche, mehrsprachige Objekttexte und feine Filter sprechen für den API-Weg.
beweglich & beidseitig
// e-03kombination
Häufig die ruhigste Lösung: Der Bestand kommt über den Export, der Rückkanal über die API. Die Website bleibt lauffähig, selbst wenn ein API-Aufruf einmal scheitert, und der Lead landet trotzdem dort, wo er hingehört. Wer klein anfangen will, startet mit dem Export und stellt die API später daneben.
bestand rein · leads raus
Der Weg ändert den Transport, nicht die Sorgfalt. Das Feld-Mapping brauchst du so oder so, die Bilder liegen in beiden Fällen lokal, und ausgeliefert wird immer aus dem eigenen Bestand statt aus einer Live-Abfrage. Auch der Umgang mit verkauften und entfallenen Objekten, die sprechenden Adressen der Objektseiten und die strukturierten Daten sind identisch — das ist Website-Arbeit, keine Eigenschaft der Schnittstelle.
Dieselbe Frage stellt sich bei jeder anderen Makler-Software: FLOWFACT und Propstack bieten eigene APIs und sprechen ebenfalls OpenImmo, PriceHubble liefert Bewertungsdaten daneben. Welcher Weg für dein Projekt trägt, klären wir im Konzept — vor dem Bauen, mit Begründung. Gebaut und beauftragt wird die Anbindung dann als Schnittstellen-Leistung.
// faq
onOffice ist eine webbasierte Software für Immobilienmakler, entwickelt von der onOffice GmbH aus Aachen, die seit 2001 am Markt ist und nach Herstellerangaben über 40.000 Nutzer zählt. Das Kernprodukt onOffice enterprise führt Objekte, Adressen und Vermarktung an einer Stelle zusammen: Immobilien mit allen Merkmalen und Bildern, Interessenten und Eigentümer als Kontakte, dazu Aufgaben, Termine, Exposés und die Übertragung an Immobilienportale. Für eine Website ist onOffice damit die führende Quelle — die Objektdaten entstehen dort und werden nicht ein zweites Mal auf der Website gepflegt.
Über zwei Wege. Der erste ist der OpenImmo-Export: onOffice legt den Objektbestand als ZIP-Paket mit einer XML-Datei und den zugehörigen Bildern per FTP oder SFTP auf dem Webserver ab, ein Import auf der Website liest das Paket ein und schreibt die Objekte ins CMS. Der zweite ist die onOffice-API: Die Website fragt Objekte, Adressen und Bilder direkt beim System ab und kann Daten auch zurückschreiben. siteway entscheidet den Weg danach, was die Website leisten soll — nicht danach, was technisch beeindruckender klingt.
Ja — in allen dreien, nur führt der Weg je nach System woanders entlang. Für TYPO3 bauen wir eine eigene Extension: das Datenmodell als TCA, der Abgleich als Scheduler-Task, die Objekte als Records in einem eigenen Systemordner, die Ausgabe über Fluid. In WordPress liegt die Anbindung in einem eigenen Plugin statt im Theme — Objekte als Custom Post Type mit eigenen Meta-Feldern, Taxonomien für die Filter, ein geplanter Lauf für den Abgleich und eine REST-Route, über die die API serverseitig abgefragt wird. In Statamic ist es reguläre Laravel-Arbeit: ein Artisan-Command im Scheduler, ein Blueprint als Datenmodell, die Objekte als Entries in einer Collection, Bilder im Assets-Container. Ob dahinter der OpenImmo-Export oder die onOffice-API steckt, ändert nur den Abgleich — nicht das Muster. Gleich bleibt in allen drei Fällen die Reihenfolge: erst das Feld-Mapping, dann der Transport, dann das Frontend.
Der OpenImmo-Export ist ein Bringdienst: onOffice schiebt ein Datenpaket auf den Server, die Website verarbeitet es. Das Format ist ein Branchenstandard des OpenImmo e. V., den auch andere Makler-Systeme sprechen — ein späterer Wechsel der Software trifft die Website deshalb kaum. Die API ist ein Holdienst: Die Website fragt gezielt ab, was sie braucht, mit Filtern, Sortierung und Umkreissuche, und kann eine Anfrage als Adressdatensatz zurückschreiben. Dafür braucht es einen API-Zugang im Kundenkonto, und jede Abfrage muss signiert und zwischengespeichert werden. Der Export ist der ruhigere Weg, die API der beweglichere.
Einen API-Benutzer im onOffice-Konto des Maklers. Angelegt wird er in onOffice enterprise; dabei entstehen ein Token mit 32 Zeichen und ein Secret mit 64 Zeichen. Das Token geht in jede Anfrage, aus dem Secret wird der HMAC berechnet, der die Anfrage signiert — dazu kommt ein Zeitstempel, der laut Dokumentation nur rund zwei Minuten gültig ist. Die Anfragen laufen als POST gegen api.onoffice.de. Zwei Punkte gehen dabei erfahrungsgemäß schief: Die API ist ein kostenpflichtiges Zusatzmodul, das freigeschaltet sein muss, und die Rechte des API-Benutzers dürfen nicht auf die eigenen Datensätze beschränkt sein, sonst kommen zu wenige Objekte zurück.
Beim OpenImmo-Export bestimmt der Turnus der Übertragung den Takt: onOffice liefert das Paket, ein Import auf der Website verarbeitet es und schreibt die Objekte fort. Bei der API fragt die Website nicht bei jedem Seitenaufruf ab, sondern holt die Daten in einem festen Intervall in einen Cache und liefert die Seiten daraus aus. Das hält die Website schnell, schont das Anfrage-Kontingent und macht sie unabhängig davon, ob das CRM gerade erreichbar ist. Für den Abgleich nutzt siteway die Änderungsfelder der API und holt nur, was sich seit dem letzten Lauf bewegt hat.
Das ist die Stelle, an der schwache Anbindungen auffallen. onOffice führt für jedes Objekt die Kennzeichen verkauft und reserviert mit — die Website kann ein Objekt damit als reserviert oder verkauft ausweisen, statt es kommentarlos verschwinden zu lassen. Fällt ein Objekt ganz aus dem Bestand, bleibt seine Adresse nicht als Fehlerseite stehen: siteway leitet dauerhaft auf die passende Objektliste um oder liefert eine Seite, die den Stand erklärt und Alternativen anbietet. So verlieren weder Besucher noch Suchmaschinen den Faden.
Objektdaten sind Sachdaten, Anfragen sind personenbezogene Daten — dieser Unterschied bestimmt die Umsetzung. Das Formular am Objekt fragt nur ab, was für die Antwort nötig ist, die Übertragung läuft verschlüsselt, und die Anfrage landet im CRM statt zusätzlich in einer Zwischenablage auf dem Webserver. Wer im Auftrag des Maklers Daten verarbeitet, braucht einen Vertrag zur Auftragsverarbeitung; das betrifft Agentur, Hoster und Software-Anbieter gleichermaßen. Was auf der Website erhoben, gespeichert und weitergegeben wird, gehört in die Datenschutzerklärung — nachvollziehbar und nicht als Textbaustein.
// womit das zusammenhängt
format, schwestern & leistung
// stack · format
Der XML-Standard hinter dem Export: Aufbau der Datei, Bilder im Paket, Übertragung und Import — unabhängig davon, welche Makler-Software dahintersteht.
zum format →
// stack · schnittstelle
Die zweite große Makler-Software im deutschen Markt — und wie ihre Objektdaten denselben Weg auf eine Website finden.
zur technik →
// stack · schnittstelle
Makler-CRM mit eigener API: Objekte, Kontakte und Anfragen zwischen System und Website — dieselben Fragen, andere Schnittstelle.
zur technik →
// stack · schnittstelle
Immobilienbewertung als Datendienst — der Baustein, der auf einer Makler-Website neben dem Objektbestand steht.
zur technik →
// stack · grundlage
Zugangsdaten serverseitig, verschlüsselte Übertragung, Datensparsamkeit im Formular: die Grundlage unter jeder Anbindung mit personenbezogenen Daten.
zur grundlage →
// leistung · buchen
Die Technik hier, das Angebot dort: Scoping, Feld-Mapping, Entwicklung, Test auf Staging und Monitoring im Betrieb. Hier wird gebucht.
zur leistung →
// Immobilien aus onOffice auf deine Website?
Projekt anfragen