Data sublicensing terms

Your legal review starts before your first API call, not after

What you can display, cache and sublicense, written down rather than negotiated.

Propalt Team · For PropTech platforms

The first thing that stops an integration is rarely the code. It is the question from your legal team: can we actually show this data to our users, keep a copy of it, and charge for it? With most property data resellers that answer arrives after a call, a redline round and a signature, weeks before you have written a line against the API. The terms are the gate, and the gate is opaque until you are already committed.

That is a fair concern to raise early rather than late. The reframe is that the terms do not need to be discovered one clause at a time. Propalt publishes the rights that matter to a platform builder up front: you may display derived data inside your product, you may cache responses for the contracted period so you are not billing a credit on every page load, and you may sublicense the output to your own paying users under defined limits. Those three rights are what a product team needs before it can scope anything, and they are stated rather than negotiated.

The three rights a platform actually needs

Display, cache and sublicense are the rights that decide whether an integration is viable, and they map cleanly onto how a product is built. Display means you can render a value returned by get_property on a screen your users see, not just consume it in a back-office process. Cache means you can store that response for the contracted period, so a property page that gets ten thousand views this month does not cost ten thousand credits. Sublicense means the value your product adds on top of the raw fields can be sold onward to your customers, within the boundaries set out in the agreement.

Each right carries a limit, and the limits are the part worth reading closely. Caching is time-bound, which matters because the underlying registers refresh on a 24h cycle and stale display data is a support problem waiting to happen. Sublicensing covers derived output rather than bulk redistribution, so you cannot resell the raw dataset as a competing feed. And attribution obligations sit alongside the display right. None of this is unusual for licensed data. What is useful is that you can read it, cost it and get sign-off before you build, rather than after your roadmap already assumes the feature ships.

The table above is illustrative. The contract governs; the point is that the shape of the answer is knowable in advance.

Why a defined licence beats a bespoke one

Every bespoke data agreement is a negotiation your legal team runs from scratch, and every renegotiation is a delay on your roadmap. A defined sublicensing model removes that loop. The rights are the same for every integrator, so your review is reading and confirming rather than drafting and countering. When your own terms of service reference the property data your product surfaces, you are pointing at a stable set of clauses, not a one-off arrangement that might shift at renewal.

The fastest integration is the one your legal team cleared before your engineers opened the spec.

For a platform team, that predictability is worth more than a marginally better line on price. You can tell your customers what they are allowed to do with the data in your product because you know what you are allowed to do with it. The chain of rights runs from register to Propalt to your platform to your user, and each link is written down.

Read the terms before you scope the feature, not after you ship it.

Try the Data sublicensing terms → · propalt.ai

Data is drawn across 29 million England and Wales properties from 8 authoritative UK registers plus the Propalt intelligence layer. Figures shown are illustrative. This article is general information for platform teams and does not constitute legal advice.