// stack · schnittstelle
FlowFact ist ein CRM für Makler und Immobilienunternehmen — dort liegen Objekte, Kontakte und Exposés. Auf die Website kommen sie über zwei Wege: den OpenImmo-Export als XML im ZIP-Archiv oder den Abruf über die API. siteway baut die Strecke dazwischen: Import, Feld-Mapping, Bilder, Turnus — und den Rückkanal, damit eine Anfrage am Objekt nicht im Postfach endet.
// definition
crm für die immobilienwirtschaft
FlowFact ist eine CRM- und Maklersoftware für die Immobilienwirtschaft: Objekte, Kontakte, Aufgaben, Termine, Exposés und die Übertragung an Immobilienportale liegen in einem System, das im Browser läuft. Rund um diesen Kern gruppieren sich die Dinge, die ein Maklerbüro täglich braucht — Suchprofil-Abgleich zwischen Interessent und Objekt, Serien-E-Mails, Kalender- und Outlook-Anbindung, automatisierte Verarbeitung von Portalanfragen.
Die Software kommt aus Köln und geht auf ein 1985 gegründetes Unternehmen zurück; seit Ende 2014 gehört FlowFact zum Scout24-Konzern. Der Hersteller nennt mehr als 6.000 Unternehmen als Anwender und Übertragungswege zu über 150 Immobilienportalen. Es gibt mehrere Produktlinien für Wohnen und Gewerbe sowie eine ältere Linie mit eigenem Serviceportal — welche im Einsatz ist, entscheidet mit, welcher Weg auf die Website offensteht.
Für eine Website ist vor allem eine Frage entscheidend, und sie ist keine technische: Wo liegt die Datenhoheit? Bei einer FlowFact-Anbindung liegt sie im CRM. Die Website ist die öffentliche Ansicht dieses Bestands — sie zeigt Objekte, sie pflegt sie nicht. Alles Weitere folgt aus dieser einen Festlegung: das Inhaltsmodell im CMS, der Turnus, der Umgang mit Abgängen.
// praxis
mapping zuerst · layout danach
Wir fangen nicht bei der Objektliste an, sondern beim Feld-Mapping. Auf der einen Seite steht, was aus FlowFact herauskommt — Objektart, Vermarktungsart, Preise, Flächen, Zimmer, Ausstattung, Energieangaben, Texte, Bilder, Dokumente. Auf der anderen Seite steht das Inhaltsmodell des CMS. Dazwischen liegt eine Tabelle, die für jedes Feld sagt: Quelle, Ziel, Datentyp, Pflicht oder optional, und was passiert, wenn es fehlt. Diese Tabelle ist die eigentliche Schnittstelle. Alles danach ist Handwerk.
Beim OpenImmo-Weg läuft es so: FlowFact packt die Objektdaten als XML-Datei zusammen mit allen referenzierten Bildern und Dokumenten in ein ZIP-Archiv und legt es per FTP im Zielverzeichnis ab — derselbe Mechanismus, mit dem auch die Portale beliefert werden. Auf der Website wartet ein Importer: Er entpackt, prüft das XML gegen das Schema, mappt die Felder, holt Medien einmalig herunter, erzeugt daraus AVIF- und WebP-Derivate und schreibt die Objekte in den Bestand. Der Lauf ist idempotent: Dieselbe Lieferung zweimal verarbeitet ergibt denselben Zustand, keine Dubletten.
Beim API-Weg dreht sich die Richtung um: Nicht das CRM liefert, sondern die Website fragt. FlowFact betreibt dafür ein öffentliches Entwicklerportal; die dort dokumentierte Cloud-API ist eine HTTPS-Schnittstelle im REST-Stil, deren Dienste nach Zuständigkeiten geschnitten sind — Entitäten und Schemata, Kontakte, Exposés, Medien, Suche, Anfragen. Die Endpunkte antworten nur mit gültigen Zugangsdaten, und der Zugang wird laut Serviceportal im CRM selbst angelegt. Was ein konkreter Vertrag freischaltet, steht nicht in der öffentlichen Dokumentation. Deshalb sichten wir vor dem Angebot immer den echten Zugang, statt aus einer Funktionsliste zu schließen — so arbeiten wir bei jeder Schnittstelle.
Der größte Hebel liegt danach im Betrieb. Ein Importer, der nur beim ersten Lauf funktioniert, ist kein Importer. Er braucht einen festen Turnus, ein Protokoll pro Lauf, eine Meldung, wenn eine Lieferung ausbleibt oder halb ankommt — und eine Regel für den Cache, damit die Auslieferung schnell bleibt, ohne dass ein geänderter Preis eine Stunde alt aussieht.
Aus dem Import wird kein Datenfriedhof, sondern eine Strecke, die ein Interessent von der Suche bis zur Anfrage durchläuft. Vier Bausteine tragen sie.
// w-01übersicht
Ort, Objektart, Vermarktungsart, Preis, Zimmer, Fläche — die Filter kommen aus den Feldern, die im Mapping als sauber typisiert markiert sind. Frei getippte Textfelder taugen nicht als Filter; das entscheidet sich vorher, nicht im Frontend.
ergebnis: einstieg in den bestand
// w-02objekt
Eine eigene, sprechende URL pro Objekt statt einer Nummer im Query-String. Galerie, Eckdaten, Beschreibungstexte, Energieangaben, Ansprechpartner, Karte — und ein Slug, der stabil bleibt, solange das Objekt online ist.
ergebnis: indexierbare landingpage
// w-03kontakt
Das Formular kennt die Objektnummer, ohne dass jemand sie abtippt. Wenige Pflichtfelder, Prüfung im Browser und auf dem Server, Bestätigungsseite statt Sackgasse — Details dazu stehen unter Formularstrecken.
ergebnis: anfrage mit kontext
// w-04rückkanal
Die Anfrage geht dorthin, wo der Interessent ohnehin geführt wird. Über die API landet sie direkt im CRM, sonst als strukturierte E-Mail, die dort verarbeitet wird. Beide Wege brauchen eine Zustellgarantie: Was nicht ankommt, muss auffallen.
ergebnis: kein lead im postfach-nirwana
// bausteine · 6 details
hier entscheidet sich, ob es trägt
Eine Objektliste bauen kann jeder. Ob eine Anbindung nach zwei Jahren noch stimmt, entscheidet sich an sechs Stellen — und keine davon sieht man auf der fertigen Seite.
// d-01transport
Eingangsverzeichnis, Sperre gegen parallele Läufe, Archiv entpacken, XML gegen das Schema prüfen, erst dann schreiben. Eine kaputte Lieferung darf den Bestand nicht anfassen — sie wird abgelehnt und gemeldet, nicht halb verarbeitet.
zweck: alles oder nichts
// d-02mapping
Der Standard kennt viele optionale Felder, und jedes Büro füllt andere. Wir mappen deshalb nicht alles, sondern das, was auf der Seite wirklich vorkommt — mit Fallback je Feld und einer Regel, was ein leeres Feld im Layout bedeutet.
zweck: daten ins inhaltsmodell
// d-03medien
Fotos, Grundrisse, Energieausweis, PDF-Exposé: Alles wird einmal geholt, über eine Prüfsumme erkannt und nur bei echter Änderung neu verarbeitet. Ausgeliefert wird lokal in modernen Formaten — nicht per Hotlink auf einen fremden Server.
zweck: schnell & unabhängig
// d-04turnus
Der Import läuft nach Plan, der Cache wird danach gezielt verworfen — für die betroffenen Objekte und die Listen, in denen sie auftauchen. So bleibt die Seite statisch schnell, ohne dass ein geänderter Preis auf den nächsten Tag wartet.
zweck: tempo trotz frische
// d-05lebenszyklus
Beim Teilabgleich meldet der Export ein entferntes Objekt ausdrücklich, beim Vollabgleich fehlt es einfach. Der Importer muss beide Modi kennen — und bei einer verdächtig kurzen Lieferung lieber abbrechen als den halben Bestand abräumen.
zweck: kein bestand aus versehen weg
// d-06betrieb
Jeder Lauf schreibt mit: wie viele Objekte kamen, was neu war, was entfiel, welches Feld nicht passte. Bleibt eine Lieferung aus oder scheitert ein Abruf, geht eine Meldung raus — bevor jemand im Büro den Fehler auf der Website entdeckt.
zweck: sichtbarer betrieb
In Richtung Website fließen Objektdaten — die sind zur Veröffentlichung bestimmt. In die Gegenrichtung fließen personenbezogene Daten von Interessenten, und dort gelten andere Regeln. Wir erheben im Formular nur, was für eine Rückmeldung nötig ist, übertragen verschlüsselt, geben nichts an Dritte weiter und sagen im Formular, wer die Daten bekommt und wozu. Wenn die Anfrage im CRM landet, verarbeitet der Anbieter sie im Auftrag des Maklerunternehmens — dafür braucht es einen Auftragsverarbeitungsvertrag zwischen beiden. Auf unserer Seite bleibt unterwegs keine Kopie länger liegen als nötig; wie wir das grundsätzlich halten, steht unter Sicherheit & Datenschutz.
Objektseiten sind Landingpages mit Verfallsdatum — das macht sie in der Suche anspruchsvoll. Drei Dinge helfen. Erstens sprechende, stabile URLs statt Parametern, damit ein Objekt überhaupt verlinkbar ist. Zweitens strukturierte Daten: Schema.org kennt mit RealEstateListing, Accommodation und Offer passende Typen — Google zeigt dafür zwar kein eigenes Rich-Result, aber die Auszeichnung macht die Seite maschinell eindeutig, und das zählt in AI-Antworten. Drittens ein sauberer Abgang: Wer verkaufte Objekte einfach stehen lässt, sammelt Seiten ein, die aussehen wie Angebote und keine mehr sind. Wer sie ersatzlos löscht, verliert Signale. Der Mittelweg ist eine Entscheidung pro Objekt — Referenz, Weiterleitung oder endgültig entfallen.
// integration
drei systeme · ein muster
Bis hierhin ging es um die Strecke. Jetzt um die Stelle, an der sie ankommt: das CMS. Der Weg dorthin ist in jedem System derselbe. Ein Import-Job holt den OpenImmo-Export ab — das Archiv mit XML und Medien —, prüft ihn gegen das Schema und legt jedes Objekt als eigenen Inhalt im CMS an: ein Datensatz je Immobilie, Felder typisiert, Bilder in der Medienverwaltung des Systems. Steht die API zur Verfügung, fragt derselbe Job die Daten stattdessen ab; am Ergebnis im CMS ändert das nichts. Das Frontend rendert daraus zwei Ansichten — die Objektliste mit Filtern und die Detailseite mit eigener, sprechender URL.
Zwei Festlegungen entscheiden über die Qualität, und beide fallen vor der ersten Zeile Code. Erstens das Datenmodell: Preis, Fläche, Zimmer, Objekt- und Vermarktungsart gehören als eigene, typisierte Felder ins CMS, nicht in einen Fließtext — sonst gibt es später weder Filter noch saubere strukturierte Daten. Welches Feld wohin geht, steht im Feld-Mapping. Zweitens der Cache: Objektseiten dürfen so statisch ausgeliefert werden wie jede andere Seite, aber der Import muss danach gezielt verwerfen, was er angefasst hat — das Objekt und die Listen, in denen es vorkommt. Was sich zwischen TYPO3, WordPress und Statamic unterscheidet, ist also nicht die Logik, sondern wo die Objekte liegen und womit der Job getaktet wird.
Wir bauen Websites in drei CMS — und in jedem davon bauen wir die Anbindung selbst, mit den Bordmitteln des jeweiligen Systems: eigenes Datenmodell, eigener Import, eigene Ausgabe. Die Logik bleibt dieselbe, nur das Bauteil heißt in jedem System anders.
// i-01enterprise
Die Anbindung bauen wir als eigene Extension auf Extbase. Sie bringt ihr Datenmodell im TCA mit — Preis, Fläche, Zimmer, Objekt- und Vermarktungsart als typisierte Felder samt Relationen —, holt die Lieferung als Task im Scheduler ab und legt jedes Objekt als Record in einem eigenen Systemordner an. Bilder gehen in die Dateiverwaltung, die Ausgabe von Objektliste und Detailseite läuft über Fluid-Templates, die sprechenden URLs kommen aus dem Site Handling. Die Redaktion pflegt danach im Backend das, was nicht aus dem CRM kommt.
// i-02verbreitet
Die Anbindung bauen wir als eigenes Plugin, nicht als Theme-Code — so überlebt sie jeden Theme-Wechsel. Das Plugin registriert die Objekte als Custom-Post-Type mit eigenen Meta-Feldern für Preis, Fläche und Zimmer und legt Objekt- und Vermarktungsart als Taxonomien an, damit die Filter der Objektliste sauber greifen. Der Import läuft als geplanter Lauf und schreibt je Objekt einen Beitrag, Bilder landen in der Mediathek. Fürs Frontend liefern wir Template und Blocks mit — die Redaktion setzt Objektliste und Detailseite damit im Editor.
// i-03flexibel
Statamic läuft auf Laravel, Inhalte sind Entries in einer Collection, das Datenmodell steht im Blueprint — genau die Struktur, die eine Objektliste braucht. Den Import bauen wir deshalb als eigenen Artisan-Command im Laravel-Scheduler: Er liest die Lieferung, schreibt je Objekt einen Entry, legt Bilder in einen Assets-Container und fasst nur an, was sich geändert hat. Antlers- oder Blade-Templates rendern Liste und Detailseite, der Static Cache wird nach dem Lauf gezielt geleert. Im Control Panel sieht die Redaktion die Objekte wie jeden anderen Inhalt und kann sie kuratieren — etwa einzelne Referenzen hervorheben.
// entscheidung
zuordnung statt rangliste
Beide Wege führen zum Ziel, sie kosten nur unterschiedlich viel — an Aufwand, an Abhängigkeit und an Genauigkeit. Die Entscheidung fällt nicht nach Geschmack, sondern nach drei Fragen: Welche Felder werden gebraucht? Wie schnell muss eine Änderung sichtbar sein? Und soll etwas zurückfließen?
// e-01standard
Objektliste, Detailseiten, Anfrage per Formular, Aktualisierung mehrmals täglich: Dafür reicht OpenImmo vollständig aus. Der Weg ist erprobt, unabhängig von Vertragsdetails und lässt sich später auf ein anderes CRM umstellen, ohne die Website neu zu bauen.
robust & portabel
// e-02api
Sobald Felder gebraucht werden, die der Standard nicht kennt, sobald eine Änderung binnen Minuten sichtbar sein soll oder sobald Leads ohne Umweg im CRM landen sollen. Die API kennt das Datenmodell des Systems, nicht nur den kleinsten gemeinsamen Nenner.
genauer & zweiseitig
// e-03kombination
In der Praxis oft die beste Antwort: Der Bestand kommt über den Export, weil er robust und wiederherstellbar ist — die Anfrage geht über die API zurück, weil sie dort sofort beim richtigen Ansprechpartner liegt. Zwei Richtungen, zwei passende Werkzeuge.
hin per export, zurück per api
Vor dem Angebot sichten wir drei Dinge: eine echte Beispiellieferung aus dem laufenden System, den tatsächlich freigeschalteten Zugang und das Inhaltsmodell der Website. Aus der Beispiellieferung lesen wir ab, welche Felder befüllt sind — nicht welche der Standard erlauben würde. Aus dem Zugang, was ein konkreter Vertrag hergibt. Und aus dem CMS, wie viel Umbau nötig ist, damit Objekte dort überhaupt sauber liegen können.
Dieselbe Systematik wenden wir bei den anderen Systemen der Branche an: bei onOffice und Propstack genauso wie bei Bewertungsdiensten wie PriceHubble. Der gemeinsame Nenner ist fast immer OpenImmo — und genau deshalb bauen wir den Importer so, dass er die Quelle wechseln kann, ohne die Website zu berühren.
// faq
FlowFact ist eine CRM- und Maklersoftware für die Immobilienwirtschaft: Objekte, Kontakte, Aufgaben, Termine, Exposés und die Übertragung an Immobilienportale liegen in einem System, das im Browser läuft. Die Software stammt aus Köln und geht auf ein 1985 gegründetes Unternehmen zurück; seit Ende 2014 gehört FlowFact zum Scout24-Konzern. Nach Herstellerangaben arbeiten mehr als 6.000 Unternehmen damit. Für eine Website ist vor allem eines wichtig: FlowFact ist das führende System für die Objektdaten — die Website zeigt sie, pflegt sie aber nicht.
Über zwei Wege. Der eine ist der OpenImmo-Export: FlowFact legt die Objektdaten als XML-Datei zusammen mit allen Bildern und Dokumenten in einem ZIP-Archiv ab und überträgt es per FTP auf den Zielserver — derselbe Mechanismus, mit dem auch Immobilienportale beliefert werden. Der andere ist die API: Die Website fragt die Daten selbst ab, mit eigenen Zugangsdaten und in einem Turnus, den wir festlegen. In beiden Fällen baut siteway die Strecke dazwischen — Import, Mapping auf das Inhaltsmodell des CMS, Medien und Auslieferung.
Ja, in allen drei Systemen. Der Weg ist überall derselbe: Ein Import-Job holt den OpenImmo-Export, prüft ihn und legt jedes Objekt als eigenen Inhalt im CMS an — in TYPO3 als Records in einem eigenen Systemordner, getaktet über einen Task im Scheduler, in WordPress als Custom-Post-Type mit eigenen Meta-Feldern und Taxonomien für die Filter, in Statamic als Entries in einer Collection, geschrieben von einem Artisan-Command im Laravel-Scheduler. Diese Anbindung baut siteway als eigenes Bauteil im jeweiligen System — als Extension, als Plugin, als Command — mit den Bordmitteln, die das System dafür mitbringt. Entscheidend ist in jedem System dasselbe: ein typisiertes Datenmodell für Preis, Fläche und Zimmer — und eine Cache-Regel, die nach dem Import gezielt greift.
OpenImmo ist ein normierter Feldsatz, den nahezu jede Maklersoftware beherrscht — dafür bekommst du genau das, was der Standard vorsieht, und die Daten sind so aktuell wie der letzte Export. Die API liefert das Datenmodell des CRM mit seinen eigenen Feldern, holt gezielt einzelne Datensätze und kann Anfragen auch zurückschreiben. Der Export ist der robustere Weg für eine Objektliste mit Detailseiten. Die API lohnt sich, wenn Felder gebraucht werden, die der Standard nicht kennt, wenn Änderungen sehr schnell sichtbar sein sollen oder wenn Leads ohne Umweg im CRM landen sollen.
Das entscheidet der Turnus, nicht die Technik. Beim OpenImmo-Weg hängt es daran, wie oft aus FlowFact exportiert wird und wie oft der Importer auf der Website nach einem neuen Archiv schaut — üblich sind Abstände von wenigen Minuten bis zu einem Lauf am Tag. Beim API-Weg bestimmt der Abrufplan das Tempo. Wir legen den Turnus bewusst fest, statt ihn so eng wie möglich zu stellen: Ein Objekt, das eine Viertelstunde später online steht, kostet nichts — ein Importer, der jede Minute läuft und dabei jedes Bild neu holt, kostet Rechenzeit und Ruhe im Betrieb.
Sie verschwinden nicht einfach. Der Abgleichsmodus sagt, wie ein Abgang gemeldet wird: Beim Teilabgleich trägt das Objekt eine Löschanweisung, beim Vollabgleich fehlt es schlicht in der neuen Lieferung. Beides muss der Importer richtig deuten, sonst bleiben Karteileichen stehen oder der halbe Bestand bricht wegen einer unvollständigen Lieferung weg. Auf der Website beantworten wir eine abgelaufene Objekt-URL danach eindeutig: als Referenz, wenn das Objekt als Referenz weiterleben soll, mit einer Weiterleitung auf die passende Objektliste oder mit dem Statuscode für endgültig entfallen. Eine Seite, die weiter aussieht wie ein Angebot, ist die schlechteste aller Antworten.
Das Formular am Objekt erhebt personenbezogene Daten, also gelten dieselben Regeln wie überall auf der Website: nur die Felder, die für eine Rückmeldung wirklich nötig sind, verschlüsselte Übertragung, keine Weitergabe an Dritte und ein klarer Hinweis darauf, wer die Daten bekommt und wozu. Landet die Anfrage in FlowFact, verarbeitet der Anbieter die Daten im Auftrag des Maklerunternehmens — dafür braucht es einen Auftragsverarbeitungsvertrag zwischen beiden. siteway baut die Strecke technisch so, dass unterwegs keine Kopie länger liegen bleibt als nötig.
Ja. Diese Seite beschreibt die Technik dahinter: Import, Feld-Mapping, Medien, Turnus, Abgänge und den Rückkanal für Anfragen. Ob eine bestehende Website dafür taugt, hängt an ihrem Inhaltsmodell — deshalb sichten wir vor dem Angebot den echten Zugang und das vorhandene CMS, statt aus einer Funktionsliste zu schließen. Die buchbare Leistung mit Konzept, Mapping, Umsetzung und Betrieb beschreibt siteway unter Schnittstellen und Integration in der Expertise.
// womit das zusammenhängt
standard, schwestern & leistung
// stack · standard
Das Austauschformat unter fast jeder Makler-Anbindung: XML im ZIP, Voll- und Teilabgleich, Abgänge. Der gemeinsame Nenner der Branche.
zum standard →
// stack · schwester
Das zweite große Makler-CRM im deutschsprachigen Raum — und wie sich seine Anbindung an eine Website von dieser hier unterscheidet.
zur schnittstelle →
// stack · schwester
Der jüngere Herausforderer im Makler-CRM-Markt. Gleiche Fragen, andere Antworten: Felder, Turnus, Rückkanal.
zur schnittstelle →
// stack · bewertung
Wenn nicht der Bestand auf die Website soll, sondern eine Bewertung als Einstieg — der Weg von der Adresse zum Lead.
zur schnittstelle →
// stack · grundlage
Wie wir Formulardaten behandeln, was verschlüsselt läuft und warum keine Interessentendaten an Dritte gehen.
zur grundlage →
// leistung · buchen
Die Technik hier, das Angebot dort: Sichtung, Feld-Mapping, Umsetzung, Monitoring nach dem Go-live. Hier wird gebucht.
zur leistung →
// Objekte aus FlowFact auf deine Website?
Projekt anfragen