// stack · schnittstelle
Propstack ist ein cloudbasiertes CRM für die Immobilienwirtschaft — und eines der wenigen Maklersysteme, die ihre REST-API öffentlich dokumentieren. Für siteway heißt das: Objektdaten kommen als JSON auf die Website statt als Kopie aus dem Exposé. Diese Seite beschreibt die zwei Wege dorthin — API und OpenImmo-Export — und wie wir sie anbinden.
// definition
Propstack ist ein cloudbasiertes CRM für die Immobilienwirtschaft, entwickelt von der Propstack GmbH. Makler, Maklerunternehmen, Franchise-Systeme und Projektvertriebe verwalten darin Kontakte, Objekte, Aufgaben, E-Mails und Termine — im Browser, ohne Installation, mit Anbindung an Microsoft 365 und Google Workspace.
Interessant wird das System an der Stelle, an der viele ältere Maklerprogramme aufhören: bei der Schnittstelle nach draußen. Propstack veröffentlicht eine REST-Dokumentation unter docs.propstack.de, mit Endpunkten für Objekte, Kontakte, Suchprofile, Dokumente und Webhooks. Wer eine Website bauen will, muss nicht raten und nicht verhandeln — es steht da.
Daneben steht der klassische Weg: der Export nach dem OpenImmo-Standard, das XML-Format, auf das sich die deutsche Immobilienbranche 2001 geeinigt hat. Beide Wege führen dieselben Objekte auf dieselbe Website. Sie unterscheiden sich in Takt, Tiefe und darin, wie viel Kontrolle die Website über die Daten bekommt.
// praxis
importieren · nicht durchreichen
Die wichtigste Entscheidung fällt vor der ersten Zeile Code: Die Website fragt das CRM nicht bei jedem Seitenaufruf. Wir importieren die Objekte in das Datenmodell des CMS — als eigene Inhaltsart mit eigenen Feldern, eigener URL und eigener Sortierung. Ausgeliefert wird danach aus dem eigenen Bestand. Das hält die Seite schnell, macht sie unabhängig von der Erreichbarkeit des CRM und sorgt dafür, dass eine Störung beim Anbieter kein weißes Objektportal produziert.
Dann kommt das Mapping. Ein Objekt in Propstack hat sehr viele Felder; eine Website braucht davon einen bewussten Ausschnitt. Wir legen fest, welches CRM-Feld auf welches Website-Feld geht, was Pflicht ist, was optional bleibt und was gar nicht erst das Haus verlässt — interne Notizen, Provisionsvereinbarungen und Eigentümerdaten gehören nicht in ein öffentliches JSON. Für mehrsprachige Auftritte liefert die API übersetzte Texte über einen locale-Parameter mit.
Bilder und Exposés ziehen wir beim Import auf den eigenen Server, statt jedes Grundrissfoto live aus dem CRM zu verlinken. Danach laufen sie durch dieselbe Bildpipeline wie der Rest der Website: skaliert, als AVIF und WebP ausgespielt, mit Maßen im Markup. Ein PDF-Exposé ist in Propstack ein Dokument mit gesetztem Exposé-Kennzeichen — es lässt sich also gezielt greifen, statt alle Anhänge zu übernehmen.
Aktualisiert wird zweigleisig: ein regelmäßiger Abgleich als Grundsicherung plus Webhooks für den schnellen Weg. Propstack ruft dafür eine Ziel-URL auf, wenn ein Ereignis eintritt, und signiert die Anfrage per HMAC-SHA256. Wir prüfen die Signatur, bevor irgendetwas verarbeitet wird — ein offener Import-Endpunkt ohne Prüfung wäre eine Einladung.
Und schließlich das, was in Angeboten gern fehlt: der Fehlerfall. Antwortet die API nicht oder unvollständig, bleibt der letzte gute Stand stehen, der Lauf wird protokolliert und mit Abstand erneut versucht. Ein abgebrochener Import darf nie den Bestand leeren. Genauso behandeln wir den Rückkanal: Geht eine Anfrage ins CRM nicht durch, ist der Lead trotzdem gesichert und geht zusätzlich per E-Mail raus — Details dazu in der Leistung Schnittstellenentwicklung.
// technik · 6 details
belegt aus der doku
Was hier steht, stammt aus der öffentlichen Dokumentation von Propstack — Endpunkte, Parameter und Ereignisnamen im Original. Feste Zahlen zu Rate Limits nennt sie nicht, deshalb behandeln wir die API als knappe Ressource: bündeln, cachen, nur nachladen, was sich geändert hat.
// d-01zugang
Die Basis ist api.propstack.de/v1. Authentifiziert wird über einen API-Key, entweder im Header X-API-KEY oder als Parameter. Die Schlüssel legt der Makler in der Propstack-Administration an und vergibt Rechte je Schlüssel — die Website bekommt einen eigenen, nicht den des Chefs.
zweck: authentifizierung
// d-02objekte
Objekte liegen unter /v1/units, einzeln unter /v1/units/:id. Gefiltert wird nach Status, Vermarktungsart, Projekt, Land und Volltext, dazu Bereiche für Preis, Miete, Fläche, Zimmer, Etage und Baujahr. Listen kommen paginiert; with_meta=1 liefert die Gesamtzahl mit.
zweck: objektbestand
// d-03aktualität
Statt zu pollen, lässt sich Propstack melden: /v1/hooks nimmt target_url und event entgegen, unter anderem property_created und property_updated. Signiert wird per HMAC-SHA256 im Header X-Propstack-Signature. Bei Änderungen liefert Propstack mit, welche Attribute betroffen sind.
zweck: ereignisgesteuert
// d-04medien
Dokumente liegen unter /v1/documents und lassen sich einem Objekt, Projekt oder Kontakt zuordnen; ein Kennzeichen markiert das PDF-Exposé. Fotos und Grundrisse holen wir beim Import ab, legen sie lokal ab und liefern sie als AVIF und WebP mit festen Maßen aus.
zweck: medien lokal
// d-05rückkanal
Anfragen gehen serverseitig an /v1/contacts. Propstack legt einen Kontakt an oder aktualisiert einen vorhandenen, wenn er über E-Mail oder eine alte CRM-ID gefunden wird — das verhindert Dubletten. Suchprofile unter /v1/saved_queries hängen am Kontakt und tragen das Objekt-Matching.
zweck: lead ins crm
// d-06export
Der zweite Weg: In Propstack wird unter Verwaltung, Portale ein Portal vom Typ FTP nach OpenImmo-Standard angelegt. Übertragen wird ein ZIP mit XML-Datei und allen referenzierten Bildern — wahlweise als Vollabgleich oder als Teilabgleich, der nur Änderungen schickt.
zweck: standardformat
Aus den importierten Daten wird kein Datenbank-Dump, sondern eine Website. Die Objektliste filtert über die Felder, die im Mapping definiert sind — Ort, Vermarktungsart, Preisspanne, Zimmer, Fläche — und arbeitet dabei auf dem eigenen Bestand, also ohne Wartezeit auf ein fremdes System. Die Detailseite bekommt eine sprechende, dauerhafte URL, die Bildergalerie, die Eckdaten als Tabelle, Lage und Ausstattung sowie das Exposé zum Download.
Darunter steht das Anfrageformular am Objekt — vorbelegt mit der Objektnummer, damit im CRM sofort klar ist, worum es geht. Von dort geht der Lead als Kontakt nach Propstack. Für Suchmaschinen ergänzen wir strukturierte Daten aus denselben Feldern, eine Objekt-Sitemap und Regeln für den Fall, dass ein Objekt aus dem Bestand fällt: umleiten, als Referenz behalten oder sauber als entfallen ausweisen.
Beim Datenschutz laufen zwei Richtungen auseinander. Objektdaten sind in der Regel unkritisch — Interessentendaten sind es nie. Deshalb: Formularfelder auf das Nötige begrenzen, Einwilligung sauber einholen und dokumentieren, Übertragung ausschließlich serverseitig über TLS, Löschfristen benennen. Und weil Propstack die Daten im Auftrag verarbeitet, gehört ein Auftragsverarbeitungsvertrag dazu — genau wie beim Hoster. Mehr dazu im Stack unter Sicherheit & Datenschutz.
// integration
drei systeme · ein muster
Die Propstack-Integration bauen wir in jedem System selbst — mit den Bordmitteln, die das CMS dafür mitbringt. Die Kette ist dabei überall dieselbe: Ein Abruf über die API oder ein eingehender Webhook stößt den Import an, die Objekte landen als Inhalte im CMS, und das Frontend rendert daraus Objektliste und Detailseite. Was dafür im CMS liegen muss, ist schnell benannt — eine eigene Inhaltsart „Objekt“ mit genau den Feldern aus dem Mapping, die Bilder in der Medienverwaltung des Systems, und die Objekt-ID aus dem CRM als Schlüssel. Über diesen Schlüssel erkennt der zweite Lauf das Objekt wieder und aktualisiert es, statt eine Dublette anzulegen. Erst dadurch werden Immobilien aus Propstack auf der Website zu echten Seiten mit dauerhafter URL statt zu einem eingebetteten Fremdinhalt.
Aktualität ist danach eine Frage von Cache und Webhook. Ausgeliefert wird aus dem eigenen Bestand, also aus Cache oder statisch erzeugten Seiten — schnell und unabhängig davon, ob das CRM gerade erreichbar ist. Meldet Propstack per Webhook eine Änderung, holen wir gezielt dieses eine Objekt nach und nehmen nur seine Detailseite und die betroffenen Listen aus dem Cache, statt die ganze Website zu leeren. Ein geplanter Lauf im Hintergrund bleibt daneben als Grundsicherung bestehen, falls ein Webhook einmal nicht ankommt. Welches CMS darunter arbeitet, ändert an dieser Mechanik nichts — nur daran, wo die Objekte am Ende liegen und was die Redaktion damit tun kann.
// cms-01typo3
TYPO3 bringt mit Extbase, TCA, dem Scheduler und Fluid alles mit, was eine Anbindung braucht. Wir bauen sie als eigene Extension: Das TCA beschreibt das Datenmodell, also die Inhaltsart „Objekt“ mit genau den Feldern aus dem Mapping. Der Abruf der Propstack-API läuft als Scheduler-Task, eingehende Webhooks nimmt eine eigene Route mit passender Middleware entgegen und aktualisiert genau ein Objekt. Die Objekte liegen als Records in einem Systemordner, Bilder und Exposés in FAL. Sprechende URLs für Liste und Detailseite kommen aus dem Site Handling, gerendert wird über Fluid-Templates. Die Redaktion sieht die Objekte im Backend, pflegt eigene Texte daneben und platziert Teaser als Content-Element auf jeder Seite.
// cms-02wordpress
In WordPress entsteht die Anbindung als eigenes Plugin und nicht als Theme-Code — so bleibt sie beim Theme-Wechsel bestehen. Die Objekte werden ein Custom Post Type mit eigenen Meta-Feldern für die Objektdaten und Taxonomien für die Filter, also Ort, Objektart und Vermarktungsart. Eine eigene REST-Route nimmt den Webhook entgegen und stößt den Abgleich für genau ein Objekt an; die Aufrufe der Propstack-API laufen serverseitig, der API-Key liegt in der Server-Konfiguration und nie im Frontend. Ein geplanter Lauf hält den Bestand als Grundsicherung nach. Fürs Frontend kommen Template-Dateien und Blöcke für den Editor dazu, damit die Redaktion Liste, Filter und Teaser dort platziert, wo sie hingehören.
// cms-03statamic
Statamic läuft auf Laravel — Inhalte sind Entries in Collections, Bilder Assets in Containern. Weil Propstack eine dokumentierte REST-API und signierte Webhooks mitbringt, lässt sich die Anbindung hier besonders sauber bauen: Ein Blueprint beschreibt das Datenmodell, ein Artisan-Command holt die Objekte und schreibt sie als Entries in eine eigene Collection, der Laravel-Scheduler bestimmt den Takt. Route und Controller nehmen den Webhook entgegen, prüfen die Signatur und aktualisieren genau ein Objekt. Fotos und Exposés landen als Assets im eigenen Container, Antlers oder Blade rendern Liste, Filter und Detailseite, Static Caching liefert sie aus. Im Control Panel pflegt die Redaktion Beschreibungstexte und Reihenfolge in Feldern, die der Import nicht anfasst.
// entscheidung
zuordnung statt rangliste
Die API ist der jüngere Weg, der Export der etabliertere. Keiner von beiden ist grundsätzlich besser — sie beantworten unterschiedliche Fragen. An drei Mustern lässt sich das zuordnen.
// e-01api
Eigene Filterlogik, gezielt gewählte Felder, mehrsprachige Objekttexte, ein Anfrageformular mit Rückkanal, Aktualisierung kurz nach der Änderung im CRM: Das ist das Terrain der REST-API. Sie gibt der Website die Kontrolle über Struktur und Takt.
json · echtzeitnah
// e-02openimmo
Läuft auf der Website ohnehin eine OpenImmo-Verarbeitung, ist der Bestand überschaubar und reicht ein Abgleich im festen Takt, dann ist der Export der kürzere Weg. Er ist portalerprobt, formatstabil und unabhängig davon, ob ein Anbieter seine API weiterentwickelt.
xml · abgleich im takt
// e-03kombination
Häufig die ehrlichste Antwort: Der Export trägt die Grundlast der Objektdaten, die API ergänzt, was er nicht sauber abbildet, und übernimmt den Rückkanal für Anfragen. Ein Weg für die Menge, ein Weg für die Präzision.
grundlast + präzision
Vier Fragen entscheiden die Richtung, und sie lassen sich in einem Gespräch beantworten. Wie viele Objekte sind im Bestand, und wie oft ändern sie sich? Welche Felder müssen wirklich auf die Website — und welche auf keinen Fall? Soll die Website Anfragen ins CRM zurückschreiben oder nur anzeigen? Und wer betreibt die Anbindung, wenn sich am CRM etwas ändert?
Danach steht das Mapping als Dokument, bevor gebaut wird. Dieselbe Logik greift bei anderen Maklersystemen: onOffice und FlowFact bringen eigene Schnittstellen mit, PriceHubble liefert Bewertungsdaten daneben, und OpenImmo ist der gemeinsame Nenner fast aller Systeme. Welche Anbindung ein Projekt bekommt, klären wir im Konzept — vor dem Bauen, mit Begründung.
// faq
Propstack ist ein cloudbasiertes CRM für die Immobilienwirtschaft, entwickelt von der Propstack GmbH. Makler, Maklerunternehmen, Franchise-Systeme und Projektvertriebe verwalten darin Kontakte, Objekte, Aufgaben, E-Mails und Termine im Browser. Für die Website zählt vor allem eines: Propstack dokumentiert seine REST-API öffentlich unter docs.propstack.de und bietet daneben den Export nach dem OpenImmo-Standard. Beide Wege führen Objektdaten aus dem CRM auf die Website, nur mit unterschiedlicher Mechanik.
Über zwei Wege. Der erste ist die REST-API: Die Website fragt die Objekte als JSON ab, übernimmt sie in ihr eigenes Datenmodell und schreibt Änderungen nach, sobald im CRM etwas passiert. Der zweite ist der OpenImmo-Export: Propstack legt ein ZIP-Archiv mit XML-Datei und Bildern per FTP ab, die Website liest es ein. In Propstack wird dieser Weg unter Verwaltung, Portale, Portal hinzufügen als FTP nach OpenImmo-Standard eingerichtet. Welcher Weg trägt, entscheidet siteway im Konzept, nicht danach, welcher moderner klingt.
Die dokumentierte Version 1 liegt unter api.propstack.de/v1. Authentifiziert wird mit einem API-Key, entweder im Header X-API-KEY oder als Parameter api_key; die Schlüssel und ihre Berechtigungen verwaltet der Makler in Propstack unter Administration und API-Keys. Objekte liegen unter /v1/units, mit Filtern für Status, Vermarktungsart, Projekt, Land und Volltextsuche sowie Bereichsfiltern für Preis, Miete, Fläche, Zimmer, Etage und Baujahr. Listen kommen paginiert, und mit with_meta=1 liefert die Antwort die Gesamtzahl mit. Eine Version 2 mit Scroll-Endpunkten für große Datenmengen ist laut Dokumentation in Arbeit.
Die API passt, wenn die Website mehr können soll als eine Liste zeigen: eigene Filter, gezielt ausgewählte Felder, mehrsprachige Texte, schnelle Aktualisierung nach einer Änderung im CRM. Der OpenImmo-Export passt, wenn ein Bestandssystem oder ein Plugin ohnehin OpenImmo spricht, wenn der Objektbestand überschaubar ist und wenn eine Aktualisierung im Takt des Abgleichs reicht. OpenImmo kennt dafür den Vollabgleich, bei dem alle Objekte erneut übertragen werden, und den Teilabgleich, bei dem nur Änderungen laufen. Und beides lässt sich kombinieren: der Export als Grundlast, die API für das, was der Export nicht sauber abbildet.
Indem die Website nicht bei jedem Seitenaufruf fragt. Die Objektdaten werden importiert und liegen danach im Datenmodell der Website; ausgeliefert wird aus dem eigenen Bestand, nicht aus einem fremden System. Aktualisiert wird über zwei Auslöser: einen regelmäßigen Abgleich als Grundsicherung und Webhooks für den schnellen Weg. Propstack meldet Ereignisse wie property_created und property_updated an eine Ziel-URL, angelegt über /v1/hooks mit target_url und event. Die Anfragen sind per HMAC-SHA256 signiert, die Signatur steht im Header X-Propstack-Signature und wird geprüft, bevor irgendetwas verarbeitet wird.
Das ist eine SEO-Frage, keine Datenfrage. Ein Objekt, das aus dem CRM verschwindet, darf keine tote URL hinterlassen. Propstack liefert den Status mit und stellt die möglichen Werte unter /v1/property_statuses bereit; das Ereignis property_updated wird laut Dokumentation auch beim Löschen ausgelöst. Daraus wird auf der Website eine feste Regel: Referenzobjekt behalten und als verkauft kennzeichnen, auf eine passende Übersicht weiterleiten oder die URL sauber als entfallen ausweisen. Was nicht passiert: dass eine Suchmaschine auf eine Seite läuft, die es nicht mehr gibt.
Ja, das ist der Rückkanal. Das Anfrageformular am Objekt schickt seine Daten serverseitig an /v1/contacts. Propstack legt daraus einen Kontakt an oder aktualisiert einen vorhandenen, wenn er über die E-Mail-Adresse oder eine mitgegebene alte CRM-ID gefunden wird, sodass keine Dubletten entstehen. Genau hier ist Datenschutz kein Nebensatz: Es gehen nur die Felder raus, die der Makler wirklich braucht, der API-Key liegt auf dem Server statt im Browser, und für die Verarbeitung im CRM braucht es einen Auftragsverarbeitungsvertrag. Die buchbare Leistung dahinter beschreibt siteway unter Schnittstellenentwicklung in der Expertise.
Ja — und in Statamic ebenso. Die Anbindung bauen wir in jedem der drei Systeme selbst, mit dessen eigenen Bordmitteln; Propstacks dokumentierte REST-API und die Webhooks machen das sauber umsetzbar. In WordPress entsteht ein eigenes Plugin: Custom Post Type mit eigenen Meta-Feldern und Taxonomien für die Filter, eine eigene REST-Route als Webhook-Endpunkt, serverseitige API-Aufrufe mit dem Schlüssel in der Server-Konfiguration und ein geplanter Lauf als Grundsicherung. In TYPO3 bauen wir eine eigene Extension mit TCA als Datenmodell, dem Abruf als Scheduler-Task, einer eigenen Route für den Webhook, den Objekten als Records in einem Systemordner und Fluid-Templates im Frontend. In Statamic liegt Laravel darunter: Blueprint als Datenmodell, Artisan-Command im Scheduler, Route mit Controller und Signaturprüfung für den Webhook, die Objekte als Entries in einer Collection. Die Integration ist damit Teil unserer Leistung — vom Datenmodell bis zum Frontend.
// womit das zusammenhängt
standard, systeme & leistung
// stack · standard
Der XML-Standard, den fast jedes Maklersystem spricht: ZIP mit XML und Bildern, Übertragung per FTP, Voll- oder Teilabgleich.
zur technik →
// stack · schnittstelle
Das verbreitete Maklersystem mit eigener Schnittstelle — anderes Modell, dieselbe Frage: Was gehört auf die Website und was nicht?
zur technik →
// stack · schnittstelle
Der langjährige Klassiker unter den CRM-Systemen für Makler und wie seine Objektdaten den Weg auf eine Website finden.
zur technik →
// stack · schnittstelle
Bewertungsdaten neben dem CRM: der Immobilienrechner auf der Website als eigener Weg zu Leads.
zur technik →
// stack · grundlage
Wo Interessentendaten fließen, wird es ernst: Schlüssel serverseitig, TLS, Datensparsamkeit, Auftragsverarbeitung.
zur technik →
// leistung · buchen
Die Technik hier, das Angebot dort: Analyse, Mapping, Umsetzung, Monitoring und Betrieb der Anbindung. Hier wird gebucht.
zur leistung →
// Objekte aus Propstack auf deine Website?
Projekt anfragen