// stack · schnittstelle
PriceHubble ist ein Anbieter datenbasierter Immobilienbewertung: Ein statistisches Modell schätzt aus Marktdaten und Objektmerkmalen, was eine Wohnung oder ein Haus wert ist — abrufbar über eine REST-API. Auf einer Makler-Website wird daraus die Online-Wertermittlung: ein paar Felder, eine Wertspanne, ein qualifizierter Kontakt. siteway baut diese Strecke serverseitig — mit den Zugangsdaten dort, wo sie hingehören, und einem Datenschutzkonzept, das der Sache angemessen ist.
// definition
PriceHubble ist ein Anbieter datenbasierter Immobilienbewertung mit Sitz in Zürich, gegründet 2016. Im Zentrum steht ein Automated Valuation Model — kurz AVM: ein statistisches Modell, das aus Marktdaten und Objektmerkmalen einen Wert schätzt, statt einen Gutachter vor Ort zu schicken. Das Ergebnis ist kein Verkehrswertgutachten und will auch keines sein. Es ist eine Einordnung, schnell und in großer Zahl reproduzierbar.
Gespeist wird das Modell aus einer eigenen Datenbank zu Wohnimmobilien. Der Anbieter beschreibt seinen Anspruch selbst so, jede Art von Daten zu sammeln und auszuwerten, die auch nur entfernt mit dem Wohnimmobilienmarkt zu tun hat — Angebots- und Transaktionsdaten, Lage- und Infrastrukturmerkmale, sozioökonomische Kennzahlen. Nach eigenen Angaben ist das Unternehmen nach ISO/IEC 27001:2022 zertifiziert und lässt das Bewertungsmodell nach dem Prüfrahmen ISAE 3000 auditieren. Zielgruppen sind Makler und Vermittler, Banken, Kreditgeber und Versicherer sowie Investoren und Verwalter.
Für eine Website zählt vor allem eines: Es gibt eine REST-API. Bewertung, Vergleichsobjekte und Umfelddaten lassen sich abrufen und im eigenen Layout darstellen — statt eine fremde Oberfläche in die Seite zu setzen. Damit wird PriceHubble zu einer Schnittstelle wie jede andere: Sie hat eine Authentifizierung, ein Datenmodell, Grenzen und Fehlerfälle. Welche Märkte und Länder die Bewertung abdeckt und welche Endpunkte im eigenen Vertrag enthalten sind, klärt man vor dem Projekt beim Anbieter — das unterscheidet sich von Kunde zu Kunde.
// praxis
schlüssel auf den server
Die Wertermittlung entsteht als eigene Strecke über die REST-API: vorne eine Formularstrecke im Design deiner Website, dahinter ein eigener Endpunkt auf deinem Server. Gestaltung, Feldreihenfolge und Consent-Verhalten liegen damit bei dir, und das Ergebnis fügt sich in die Seite ein, statt daneben zu stehen. Die Oberfläche gehört dir — und mit ihr der Lead, der daraus entsteht.
Gebaut wird sie über einen serverseitigen Proxy. Die Zugangsdaten liegen in der Server-Konfiguration, nie im JavaScript-Bundle. Der Browser schickt die Formularangaben an einen eigenen Endpunkt der Website; der spricht mit PriceHubble und gibt nur das Ergebnis zurück. Die Anmeldung läuft laut Herstellerdokumentation über einen Aufruf gegen auth/login/credentials, der ein Zugriffstoken mit zwölf Stunden Gültigkeit liefert; anschließend geht jede Anfrage mit einem Authorization: Bearer-Header an die versionierte Basis-URL. Dieses Token halten wir vor, statt es bei jedem Aufruf neu zu holen — die Dokumentation warnt ausdrücklich davor, dass zu viele Anmeldungen eine zeitweilige Sperre auslösen. Genau dasselbe Muster nutzen wir bei unseren eigenen Tools: Der Browser sieht die fremde API nie.
Vorne steht die Formularstrecke, und die halten wir kurz. Adresse, Objektart, Wohnfläche, Baujahr — mehr braucht das Modell für eine erste Einordnung nicht. Wir teilen das in wenige Schritte mit sichtbarem Fortschritt, prüfen jede Eingabe direkt am Feld und noch einmal auf dem Server, und wir fragen die Kontaktdaten zuletzt — wenn die Objektangaben stehen und das Ergebnis unmittelbar bevorsteht. Wer den Kontakt vor die Rechenstrecke stellt, verliert die Hälfte der Leute im ersten Schritt. Wie wir solche Strecken grundsätzlich schneiden, steht unter Formularstrecken und Lead-Magnet-Formulare.
Das Ergebnis zeigen wir sofort, auf derselben Seite, als Spanne mit der Verlässlichkeitsangabe des Modells — nicht als Punktwert und nicht erst nach Rückruf. Parallel geht der Lead dorthin, wo er bearbeitet wird: ins Makler-CRM, mit Feld-Mapping, Fehlerbehandlung und Protokoll. Und weil eine Wertermittlung technisch eine Rechenstrecke mit Ergebnisseite ist, gilt für sie dasselbe Baumuster wie für Konfiguratoren: Zustand im Server führen, Ergebnis reproduzierbar halten, jede Annahme benennen.
// bausteine · 6 details
nach der herstellerdoku
Die folgenden Punkte stehen so in der öffentlichen Entwicklerdokumentation von PriceHubble. Was im konkreten Projekt tatsächlich freigeschaltet ist, hängt am Vertrag — deshalb klären wir den Umfang, bevor wir spezifizieren.
// d-01zugang
Benutzername und Passwort gehen als JSON gegen den Login-Endpunkt, zurück kommt ein Zugriffstoken mit einer Gültigkeit von zwölf Stunden. Danach trägt jede Anfrage einen Authorization-Header im Bearer-Format. Das Token gehört in den Server-Cache — nicht in den Browser und nicht in jeden Request neu.
zweck: zugriff absichern
// d-02bewertung
Valuation Light bewertet ein einzelnes Objekt mit wenigen Angaben — für eine Wertermittlung auf der Website meist genau richtig. Der vollständige Valuation-Endpunkt nimmt mehr Merkmale, mehrere Objekte oder mehrere Stichtage in einem Aufruf, laut Dokumentation bis zu fünfzig Bewertungen.
zweck: passend dimensionieren
// d-03eingabe
Pflicht sind die Lage — als Adresse oder als Koordinaten — und die Objektart, dazu das Länderkürzel und ob es um Verkauf oder Vermietung geht. Ergänzend nimmt das Modell Angaben wie Wohnfläche und Baujahr. Genau diese Felder bildet die Formularstrecke ab, keines mehr.
zweck: datensparsam fragen
// d-04ergebnis
Zurück kommt eine Wertspanne mit Unter- und Obergrenze samt Währung, dazu eine Einstufung der Verlässlichkeit in drei Stufen. Der vollständige Endpunkt ergänzt einen geschätzten Verkaufspreis und eine geschätzte Bruttomiete. Wir zeigen die Spanne — sie beschreibt ehrlicher, was ein Modell leisten kann.
zweck: ehrliche darstellung
// d-05umfeld
Neben der Bewertung führt die Dokumentation weitere Endpunkte auf — unter anderem sozioökonomische Daten, Punkte von Interesse in der Umgebung, Erreichbarkeiten, Bauprojekte, Preisindizes und das Dossier als teilbaren Bericht. Für eine Website nehmen wir davon nur, was die Seite wirklich trägt.
zweck: kontext statt zahlenwust
// d-06betrieb
Eine fremde API kann langsam sein, ein Token ablaufen, eine Adresse unauflösbar bleiben. Also: Zeitlimit setzen, einmal kontrolliert wiederholen, dem Menschen im Formular einen verständlichen Satz zeigen statt eines Fehlercodes — und den Kontakt trotzdem sichern, damit aus einem Ausfall kein verlorener Lead wird.
zweck: robust bleiben
// integration
drei systeme · ein muster
Die Wertermittlung auf der Website ist unsere Leistung, und wir bauen sie als eigene Strecke über die REST-API. Sie besteht aus zwei Teilen: vorne eine Formularstrecke, die das CMS ausliefert und die Redaktion pflegt — dahinter ein serverseitiger Proxy-Endpunkt, der die Zugangsdaten hält, die Anfrage validiert, die API aufruft, das Ergebnis aufbereitet und den Lead übergibt. Dieses Muster ist in TYPO3, WordPress und Statamic dasselbe. Was sich unterscheidet, ist der Ort, an dem der Endpunkt sitzt, und die Oberfläche, in der die Redaktion arbeitet.
Diese Strecke unterscheidet sich grundlegend von einer CRM-Anbindung. Dort holt ein Job Datensätze ab und legt sie im CMS an; hier entsteht überhaupt kein Import. Der Endpunkt hält das Token vor und reicht die Anfrage an PriceHubble weiter. Im CMS liegt alles, was die Redaktion anfassen soll: die Seite selbst, die Formularfelder und ihre Beschriftungen, Hilfe- und Hinweistexte, der Einwilligungstext und der Aufbau der Ergebnisdarstellung. Serverseitiger Code ist der Rest — Anmeldung, Token-Cache, Validierung, Aufruf, Fehlerbehandlung und die Übergabe des Leads. Und quer über alle Systeme gilt derselbe Satz: Der API-Zugang bleibt in der Server-Konfiguration, nicht im Frontend-JavaScript, denn was der Browser lädt, kann jeder lesen.
// i-01typo3
Hier bauen wir eine eigene Extension, per Composer installiert. Der Proxy-Endpunkt sitzt darin als PSR-15-Middleware oder als Controller-Action mit eigener Route — er nimmt die Formularangaben entgegen, spricht mit der API und gibt nur das Ergebnis zurück. Die Zugangsdaten liegen in der Extension-Konfiguration beziehungsweise in Umgebungsvariablen, nie im Template. Die Redaktion setzt das Plugin-Element auf eine Seite und pflegt Feldbeschriftungen, Hinweis- und Einwilligungstexte im Backend; die Ergebnisdarstellung liegt im Fluid-Template.
// i-02wordpress
Die Logik gehört in ein eigenes Plugin, nicht ins Theme — dann übersteht sie jeden Theme-Wechsel. Der Proxy-Endpunkt entsteht als eigene REST-Route unter eigenem Namespace, alternativ als Action über admin-ajax.php. Der Schlüssel steht in der Konfiguration, etwa als Konstante in der wp-config.php oder als Umgebungsvariable. Die Redaktion setzt Block oder Shortcode auf eine Seite und pflegt Texte, Feldbeschriftungen und den Einwilligungshinweis über die Einstellungen des Plugins.
// i-03statamic
Statamic läuft auf Laravel, und damit ist der Weg der kürzeste von den dreien: eine Route plus Controller im Framework-Unterbau, dazu ein HTTP-Client für den Aufruf und der Cache für das Token. Der Schlüssel steht in der .env und wird über eine Config-Datei gelesen. Die Redaktion pflegt die Seite als Entry: Felder, Beschriftungen und Texte kommen aus dem Blueprint, die Ergebnisdarstellung aus dem Antlers- oder Blade-Template.
// datenschutz
kein nebenschauplatz
Eine Online-Wertermittlung ist kein anonymer Rechner. Sie verbindet die Adresse einer bestimmten Immobilie mit Name, E-Mail-Adresse und oft Telefonnummer — und mit der Absicht, zu verkaufen. Das ist ein sensibler Datensatz, und er entsteht in dem Moment, in dem jemand auf „Ergebnis anzeigen“ klickt. Wer das wie ein Kontaktformular behandelt, behandelt es falsch.
Deshalb klären wir vor dem Bauen fünf Dinge. Erstens die Rechtsgrundlage: Die Bewertung selbst ist Teil der angefragten Leistung — die spätere werbliche Ansprache ist es nicht und braucht eine eigene, aktiv erteilte Einwilligung mit klarer Beschreibung, ein vorangekreuztes Kästchen genügt nicht. Zweitens die Zweckbindung: Was für die Wertermittlung erhoben wurde, wandert nicht ungefragt in den Newsletter-Verteiler. Drittens die Auftragsverarbeitung: Die Daten gehen an einen Dienstleister, also braucht es einen Vertrag nach Artikel 28 DSGVO, dazu die Angaben zu Verarbeitungsorten und etwaigen Unterauftragnehmern.
Viertens die Datensparsamkeit: Jedes Feld muss sich begründen lassen. Das Modell braucht Lage, Objektart, Fläche und Baujahr — die Telefonnummer braucht der Makler, nicht die API, und sie bleibt deshalb optional. Fünftens die Transparenz: Die Datenschutzerklärung nennt den Bewertungsanbieter, den Zweck, die Rechtsgrundlage und die Löschfrist; im Formular steht der Hinweis dort, wo entschieden wird, nicht im Fußbereich.
Die Architektur hilft dabei. Beim serverseitigen Proxy geht die Anfrage von unserem Server aus — der Browser der Besucherin baut keine Verbindung zu einem fremden Host auf, und wir bestimmen, welche Felder überhaupt weitergereicht werden. Erhoben wird nur, was die Bewertung wirklich braucht, und die Einwilligung steht dort, wo die Kontaktdaten abgefragt werden. Wie wir Websites grundsätzlich trackingfrei und mit sauberen Security-Headern ausliefern, steht im Stack unter Sicherheit & Datenschutz.
// entscheidung
zuordnung statt rangliste
Eine Wertermittlung auf der Website ist ein Versprechen: sofort eine Zahl, dafür deine Adresse. Das trägt dann, wenn hinter dem Kontakt ein Prozess steht, der ihn auch bearbeitet. An drei Zeichen erkennen wir, dass es passt — darunter steht, was sonst der bessere Baustein ist.
// e-01markt
Ein Modell braucht Vergleichsdaten. In Lagen mit vielen Transaktionen und typischen Objekten liefert es belastbare Korridore. Wer überwiegend Sonderobjekte vermittelt, bekommt breite Spannen — und sollte das Werkzeug anders zuschneiden.
datendichte entscheidet
// e-02prozess
Ein Kontakt, der drei Tage liegen bleibt, ist ein verbrannter Kontakt. Die Strecke lohnt sich, wenn eine Person zuständig ist, das CRM den Datensatz sofort bekommt und eine Nachfassroutine existiert. Sonst produziert die Website nur Datenschutz-Aufwand.
technik braucht anschluss
// e-03haltung
Wer die Zahl hinter einem Rückruf versteckt, verkauft ein Formular als Rechner. Das spricht sich herum. Die Strecke trägt, wenn die Spanne direkt erscheint — inklusive des Hinweises, dass eine Besichtigung sie nach oben oder unten verschieben kann.
offenheit wirkt
Geht es um Gewerbe, Spezialimmobilien oder Objekte mit ungewöhnlichem Zuschnitt, ist ein Rechner das falsche Versprechen — dort führt ein gut geschnittenes Anfrageformular mit qualifizierenden Fragen schneller zum Gespräch. Wer Sichtbarkeit statt Kontaktdaten sucht, ist mit Marktberichten oder einem Ratgeber als Lead-Magnet besser bedient: weniger Datenschutzgewicht, längere Wirkung.
Und wenn ohnehin ein Objektbestand auf der Website liegt, ist die Reihenfolge oft umgekehrt: Erst fließen die Objekte über OpenImmo aus dem Maklersystem auf die Seite, dann kommt die Wertermittlung als zweiter Schritt dazu. Was in welcher Reihenfolge gebaut wird, klären wir im Konzept — vor dem Bauen, mit Begründung.
// faq
PriceHubble ist ein Anbieter datenbasierter Immobilienbewertung mit Sitz in Zürich, gegründet 2016. Kern ist ein Automated Valuation Model, kurz AVM: ein statistisches Modell, das aus Marktdaten und Objektmerkmalen einen Wert schätzt, statt einen Gutachter vor Ort zu schicken. Genutzt wird das laut Anbieter von Maklern und Vermittlern, von Banken, Kreditgebern und Versicherern sowie von Investoren und Verwaltern. Für Websites ist vor allem die REST-API interessant: Sie liefert Bewertungen und Umfelddaten an das eigene System, das die Darstellung selbst gestaltet.
Über einen serverseitigen Proxy. Die Zugangsdaten liegen in der Server-Konfiguration, nie im JavaScript. Der Browser schickt die Formularangaben an einen eigenen Endpunkt der Website, dieser holt sich bei PriceHubble ein Zugriffstoken und fragt die Bewertung ab; zurück an den Browser geht nur das Ergebnis. Die Formularstrecke davor gestalten wir im Design deiner Website, damit Eingabe, Ergebnis und Kontaktabfrage zur Seite passen.
Ja, und in Statamic ebenso. Die Strecke ist in allen drei Systemen dieselbe: eine Formularstrecke, die das CMS ausliefert, und ein serverseitiger Proxy-Endpunkt, der die Zugangsdaten hält, die Anfrage validiert, die API aufruft, das Ergebnis aufbereitet und den Lead übergibt. In TYPO3 bauen wir dafür eine eigene Extension mit Middleware oder Controller-Route, in WordPress ein eigenes Plugin mit eigener REST-Route, in Statamic eine Route mit Controller im Laravel-Unterbau. Der API-Zugang liegt in allen drei Fällen in der Server-Konfiguration — in der Extension-Konfiguration, in der wp-config.php oder in der .env — und nie im Frontend-JavaScript. Die Redaktion pflegt Seite, Formularfelder, Hinweistexte und Ergebnisdarstellung im gewohnten Backend.
Weil alles, was im Browser landet, lesbar ist. Die PriceHubble-API arbeitet mit Zugangsdaten, gegen die ein Zugriffstoken ausgestellt wird; laut Herstellerdokumentation ist dieses Token zwölf Stunden gültig und wird als Authorization-Header im Bearer-Format mitgeschickt. Läge es im Frontend, könnte es jeder auslesen und auf fremde Rechnung Abfragen stellen. Deshalb spricht bei uns ausschließlich der Server mit der Schnittstelle — und er hält das Token vor, statt es bei jedem Aufruf neu zu holen, denn die Dokumentation warnt ausdrücklich vor einer zeitweiligen Sperre, wenn zu viele Anmeldungen auflaufen.
Das hängt vom Endpunkt ab. Der schlanke Endpunkt Valuation Light gibt laut Dokumentation eine Wertspanne mit Unter- und Obergrenze zurück, dazu die Währung und eine Einschätzung der Verlässlichkeit in den Stufen poor, medium und good. Der vollständige Valuation-Endpunkt liefert zusätzlich einen geschätzten Verkaufspreis samt Spanne und eine geschätzte Bruttomiete. Auf einer Website zeigen wir bevorzugt die Spanne: Eine Modellschätzung ohne Innenbesichtigung ist ein Korridor und kein Gutachten — wer das offen sagt, verliert damit kein Vertrauen, sondern gewinnt es.
Wenige — und mehr sollte auch nicht abgefragt werden. Für eine Bewertung genügen laut Dokumentation die Lage über Adresse oder Koordinaten und die Objektart, dazu Angaben wie Wohnfläche und Baujahr sowie die Information, ob es um Verkauf oder Vermietung geht und in welchem Land das Objekt liegt. Alles andere ist Beiwerk und kostet Abschlüsse. Die Kontaktdaten fragen wir erst ab, wenn die Objektangaben stehen und das Ergebnis unmittelbar bevorsteht.
Nein, sie braucht Sorgfalt. Die Adresse einer Immobilie zusammen mit Name, E-Mail-Adresse und Telefonnummer ergibt einen personenbezogenen Datensatz, und der Zweck ist ein anderer als bei einem Kontaktformular. Nötig sind eine tragfähige Rechtsgrundlage samt Einwilligung für die spätere Ansprache, ein Vertrag zur Auftragsverarbeitung mit dem Bewertungsanbieter, ein Eintrag in der Datenschutzerklärung, klare Löschfristen und die Beschränkung auf die Felder, die das Modell wirklich braucht. Die Grundsätze dahinter beschreibt siteway im Stack unter Sicherheit & Datenschutz.
Ja, sofern das CRM eine Schnittstelle dafür anbietet. Im deutschsprachigen Maklermarkt sind onOffice, FlowFact und Propstack die verbreiteten Systeme, und die Übergabe ist derselbe Handgriff wie bei jeder anderen Anbindung: Feld-Mapping, Übertragung, Fehlerbehandlung und ein Protokoll, das zeigt, ob der Datensatz angekommen ist. Wichtig ist, dass ein System führt und die anderen folgen, damit derselbe Kontakt nicht doppelt entsteht. Wie siteway solche Anbindungen baut, steht in der Expertise unter Schnittstellen & Integration.
// womit das zusammenhängt
daten, systeme & leistung
// stack · datenformat
Der Standard, über den Objektdaten aus dem Maklersystem auf die Website kommen. Die Wertermittlung liefert Leads herein, OpenImmo bringt Objekte heraus.
zum format →
// stack · crm
Eines der Systeme, in denen der Lead landen soll. Ohne Anschluss ans CRM bleibt jede Wertermittlung eine hübsche Rechenstrecke ohne Wirkung.
zum system →
// leistung · buchen
Die Technik hier, das Angebot dort: Scoping, Feld-Mapping, Entwicklung, Test auf Staging und Monitoring im Betrieb. Hier wird gebucht.
zur leistung →
// Wertermittlung auf deiner Website?
Projekt anfragen