Real Estate & Property
Rental Price Intelligence API
Lettings pricing is usually set by looking at three current listings nearby. Those are asking rents from landlords who have not yet found a tenant.
- Lettings agents
- Build-to-rent operators
- Property portals
- Buy-to-let investors
- Property management software
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
The gap between asking rent and achieved rent is where lettings money is lost. A property listed slightly above the market sits empty for five weeks, and the void costs more than the extra rent would have earned over the whole tenancy. A property listed slightly below lets in four days to the first applicant, and the agent never learns what it could have achieved.
Agents price from comparable listings because that is the data they can see. Achieved rents are far harder to assemble: they sit in tenancy agreements, in property management systems, and in deposit registration records, scattered across whoever happens to hold them. The result is a market priced on the asks of landlords who are, by definition, still waiting.
Rental markets also move differently from sales markets. They are more seasonal, more sensitive to local supply shocks such as a single new development completing, and they re-price far faster. A rental model built on annual averages will miss the thing an operator most needs to know, which is what happened to the market in the last six weeks.
Who buys this
Lettings agents, Build-to-rent operators, Property portals, Buy-to-let investors, Property management software
What the API returns
What comes back
- Expected achieved rent with a range, by property and tenancy type
- Expected time to let at a given asking rent, and the implied void cost
- Asking-rent against achieved-rent gap for the local market
- Neighbourhood comparison at several geographic scales, with sample sizes
- Rental trend series with seasonality separated from underlying movement
- Yield calculation when combined with a purchase or valuation figure
- Attribute premiums: furnishing, parking, outdoor space, bills included, pets
- Supply pressure indicators, including new-build completions entering the local market
Endpoints
| Method | Path | Returns |
|---|---|---|
| GET | /v1/rent/estimate | Expected rent for a property by address and attributes |
| GET | /v1/rent/time-to-let | Expected letting period at a given asking rent |
| GET | /v1/areas/{id}/comparison | Neighbourhood rental comparison with sample sizes |
| GET | /v1/areas/{id}/trend | Rental trend series with seasonal decomposition |
| POST | /v1/portfolio/rent-review | Rent-review positions across a portfolio |
| POST | /v1/tenancies/ingest | Push achieved rents from your own tenancy records |
Request and response
illustrativeRequest
{
"address": { "line1": "Flat 6, 18 Beckworth Street", "postcode": "M4 5JN", "country": "GB" },
"attributes": {
"bedrooms": 2,
"bathrooms": 1,
"floor_area_sqm": 61,
"furnished": "part",
"parking": false,
"outdoor_space": "balcony",
"bills_included": false
},
"tenancy_type": "assured_shorthold_12m",
"include": ["time_to_let", "comparison", "premiums"]
}Response
{
"expected_rent_pcm": 1180,
"currency": "GBP",
"range_80": [1120, 1245],
"based_on": { "achieved_tenancies_12m": 84, "listings_12m": 212, "radius_m": 600 },
"time_to_let": [
{ "asking_pcm": 1120, "expected_days": 9, "let_probability_30d": 0.96 },
{ "asking_pcm": 1180, "expected_days": 17, "let_probability_30d": 0.88 },
{ "asking_pcm": 1275, "expected_days": 41, "let_probability_30d": 0.52,
"void_cost_vs_1180": 790 }
],
"market": {
"asking_to_achieved_gap_pct": -3.4,
"trend_12m_pct": 6.1,
"trend_3m_annualised_pct": 2.2,
"seasonal_position": "off_peak"
},
"attribute_premiums": [
{ "attribute": "parking", "premium_pcm": 65 },
{ "attribute": "balcony", "premium_pcm": 28 },
{ "attribute": "fully_furnished", "premium_pcm": 40 }
],
"supply_pressure": { "band": "elevated",
"note": "312 units completing within 1km in the next two quarters" }
}Where the data comes from
| Your own tenancy records | Achieved rents, start dates and void periods from your management system — the most valuable input and the one no external vendor has |
| Licensed portal listing data | Asking rents and listing durations, where a licence or partnership permits commercial use of the data rather than mere viewing |
| Deposit and tenancy registration data | Where a jurisdiction publishes or licenses it, this is the closest thing to a public achieved-rent record |
| Property attribute and energy-certificate records | Floor area, type and condition proxies, which carry a large share of the rent explanation |
| Planning and new-build pipeline data | Completions entering a local market, which move rents faster than almost anything else |
| Geospatial amenity and transport data | Access, catchments and neighbourhood features, from licensed and open sources |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Separate models for achieved rent and for time-to-let, because they answer different questions and an operator needs both to price
- Survival modelling for letting duration, which handles properties still on the market without discarding them as missing data
- Asking-to-achieved calibration estimated per local market, since the discount varies substantially between tight and loose markets
- Attribute premium estimation with hierarchical pooling, so a premium for parking is not fitted from four observations in one postcode
- Seasonal decomposition at local level, so a six-week slowdown is correctly read as seasonal rather than structural
- Supply-shock features from the new-build pipeline, lagged to completion rather than to planning consent
- Validation against held-out achieved tenancies with error reported by area, bedroom count and price band
- Monitoring on sample depth per area, with suppression where the achieved-rent count falls below a publishable threshold
What it changes for the business
Shorter voids
Pricing against expected time-to-let rather than against neighbours' asks removes most avoidable empty weeks.
Defensible rent reviews
A range with comparables and sample sizes behind it is a far easier conversation with a landlord or tenant.
Better acquisition decisions
Investors can underwrite a purchase on an expected achieved rent rather than an optimistic listing figure.
Portfolio visibility
Operators can see which units are under-rented and which are priced above what the market is actually paying.
How it fits into your product
How it embeds
- Single call by address for use inside a valuation or instruction workflow
- Portfolio endpoints for scheduled rent-review runs across a managed book
- Ingestion of your own achieved tenancies, which materially improves the model for your markets
- Connectors for the common property management platforms, plus file ingestion where needed
- Embeddable comparison and trend components, or raw JSON for your own front end
- Deployment inside your environment where tenancy data cannot leave your infrastructure
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 12 weeksDiscovery and data review
Weeks 1–2
We agree the exact question the API answers, review the sources you already hold, check what has to be licensed, and write down the response contract your developers will code against.
Architecture and prototype
Weeks 3–4
You get a written architecture plus a working endpoint on real data — narrow, but genuinely callable — so integration can be tested against something concrete rather than a document.
Production build
Weeks 5–10
Pipelines, models, storage, authentication, rate limiting, logging, tests and documentation. Security and observability are part of this phase, not a later one.
Integration and handover
Weeks 11–12
We support your engineers through their integration, run load tests at your expected volume, and agree how the service is monitored and supported once it is live.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
Do you have achieved rents or just asking rents?
It varies by market, and we are specific about it rather than blurring the two. Some jurisdictions publish or license registration data that approximates achieved rents; many do not. Where we only have asking rents we model the asking-to-achieved gap and widen the range accordingly, and the response states which basis was used. Your own tenancy records, if you have them, close this gap better than anything we could buy.
How granular can the estimate be?
As granular as the data supports, which is often street level in dense cities and no better than a wide district in sparse areas. The response carries the sample size and radius used, so a figure built on eleven comparable tenancies is distinguishable from one built on two hundred.
Can it price unusual properties?
Poorly, and it will say so. Single-property conversions, houses in multiple occupation with unusual configurations, and high-end lettings with no local comparable all fall outside what a comparables-based model can do well. For those the API returns a wide range or declines, rather than producing a tidy number from nothing.
Does it account for new developments opening nearby?
Yes, as a supply-pressure indicator from the completions pipeline, which is one of the few genuinely forward-looking signals in rental markets. The magnitude of the effect is estimated and uncertain — a large scheme letting up over two quarters affects nearby rents, but how much depends on how it is priced, which we cannot know in advance.
Can we use portal listing data we scrape ourselves?
Only if your arrangement with that portal permits it, and most portal terms do not permit automated collection or commercial reuse. Several operate licensing or partner programmes that do, and that is the route we would pursue. We check this in discovery because building a pricing product on data you are not licensed to use is a problem that surfaces at the worst possible time.
Related blueprints
Automated Property Valuation API
Estimated property values with confidence ranges and the comparable sales behind them, as a valuation endpoint your portal or lending flow can call.
Property Investment Scoring API
Yield, vacancy risk, expense estimates and appreciation scenarios for a property or a portfolio, returned as a scored investment assessment.
Construction Cost Estimation API
Material, labour and whole-project cost estimates with regional adjustment and a stated uncertainty range, for early-stage feasibility and pricing.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.