The best data tool is the one the adviser never has to open
One API and an OpenAPI 3.1 specification place valuation, tenure and property detail inside the fact-find an adviser already completes.
Propalt Team · For mortgage brokers
Every advice firm has a graveyard of tools that were bought, logged into twice, and then quietly abandoned. The reason is almost never the data. It is the switch. An adviser working through a fact-find will not break their flow to open a separate portal, copy an address across, and read a result in another window. If the property intelligence is not on the screen they already use, it may as well not exist.
The fix is not another login. It is putting the data where the work already happens. One API call, described by a standard OpenAPI 3.1 specification, lets your platform team pull valuation, tenure and property detail straight into the fact-find your advisers already fill in.
One API, a standard spec, no house style to learn
Integration teams do not want a bespoke protocol to reverse-engineer. They want a documented API and a spec they can point their tooling at. An OpenAPI 3.1 specification means the endpoints, the fields and the response shapes are described in a format your developers' existing tools already read, so client generation, validation and testing follow the path they use for every other service. The property data becomes just another field on the form, populated as the adviser types the address.
| Approach | Adviser action | Where the data appears | Adoption |
|---|---|---|---|
| Separate portal | Log in, copy address, switch back | Another tab | Low, fades fast |
| Adviser platform feed | None beyond the address | Inside the fact-find | High, because it is automatic |
The table is illustrative of the pattern, not a measured study. The principle holds regardless: data that arrives without an extra action gets used, and data behind a login gets forgotten.
Build it once, and every adviser benefits
The honest concession is that this route needs platform work up front. Someone has to wire the API into your fact-find. Reframe that against the alternative: buying seats in a standalone tool that most advisers stop opening within a fortnight. A single integration, built once, puts consistent property data in front of every adviser on every case, with no behaviour change asked of them. For a network or a larger firm, that is the difference between a data subscription that shows up in usage reports and one that shows up in outcomes.
The tool with the best data loses to the tool that is already open. So put the data in the tool that is already open.
Meet the adviser inside the screen they already work in.
Try the Adviser platform feed → · propalt.ai
Property and valuation data is drawn from HM Land Registry and the Propalt intelligence layer. Figures shown are illustrative. This article is general information for mortgage professionals.
Adviser platform feed
Exposes property and valuation data through a single API described by an OpenAPI 3.1 specification, so it can be pulled straight into an existing fact-find rather than living in a separate tool.
🎯 Best used for
Embedding property data inside an existing adviser platform
🔌 Propalt APIs used
get_property get_valuation_by_property_id
