Home/Offers/Real Estate & Property/Listing Quality API

Real Estate & Property

Listing Quality API

The same flat appears four times on your portal, listed by three agents at two prices, and one of those listings was let six weeks ago.

Property portals
Estate agency software
Lettings platforms
Marketplaces
Trust and safety teams

Discuss This Build See What It Returns

What your customers would see

example interface

MockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.

The problem this solves

Portal listing quality degrades in predictable ways. Multi-agency instructions produce genuine duplicates with different photography and different asking prices. Agents relist to refresh a listing's position rather than editing it. Properties that have let or sold stay live because taking them down is nobody's priority. Each of those makes search results worse, and search results are the product.

Missing detail is the quieter problem. A listing without a floor area cannot be filtered by size, one without an energy rating fails an increasing number of disclosure expectations, and one with three photographs converts far worse than one with fifteen. Portals know this and ask agents to improve their listings; without a per-listing quality score and a specific list of what is missing, the request is too vague to act on.

Then there is the small share of listings that are not what they claim. Rental fraud follows recognisable patterns — a price well below the local market, photographs lifted from another listing, a newly registered advertiser, pressure to pay a holding deposit before viewing. Those patterns are detectable, and treating them as signals for review rather than grounds for automatic removal is the only defensible design.

Who buys this

Property portals, Estate agency software, Lettings platforms, Marketplaces, Trust and safety teams

Category: Real Estate & Property

What the API returns

What comes back

Per-listing quality score with the missing and weak fields itemised
Duplicate and near-duplicate clusters across agents, with the canonical listing identified
Stale-listing detection from market signals and listing behaviour
Price plausibility against the local market, flagged in both directions
Image checks: duplication across listings, resolution, count, watermarks, interior coverage
Description quality signals including boilerplate reuse and contradictions against the structured fields
Fraud-risk indicators with the contributing signals itemised, for human review
Agent and branch level quality aggregation, for feed management conversations

Endpoints

Method	Path	Returns
POST	/v1/listings/score	Score one or many listings for quality
POST	/v1/listings/duplicates	Detect duplicate and near-duplicate clusters
GET	/v1/listings/{id}/issues	Itemised issues and missing fields for one listing
GET	/v1/queue/suspicious	Prioritised review queue of listings with fraud indicators
GET	/v1/agents/{id}/quality	Aggregated feed quality for an agent or branch
POST	/v1/outcomes	Record moderation outcomes to recalibrate scoring

Request and response

illustrative

Request

{
  "listing": {
    "id": "lst_2210884",
    "agent_id": "ag_4412",
    "type": "rent",
    "address_text": "Flat 6, 18 Beckworth Street, Manchester",
    "asking_pcm": 720,
    "bedrooms": 2,
    "floor_area_sqm": null,
    "epc_band": null,
    "description": "Stunning 2 bed apartment available now, must be seen, no time wasters.",
    "images": ["https://cdn.example.com/l/a.jpg", "https://cdn.example.com/l/b.jpg"],
    "first_published": "2026-10-19"
  },
  "include": ["duplicates", "price_check", "image_checks", "fraud_signals"]
}

Response

{
  "listing_id": "lst_2210884",
  "quality_score": 34,
  "band": "poor",
  "missing_fields": [
    { "field": "floor_area_sqm", "impact": "excluded_from_size_filters" },
    { "field": "epc_band", "impact": "disclosure_expectation" },
    { "field": "available_from", "impact": "search_ranking" }
  ],
  "weak_fields": [
    { "field": "images", "detail": "2 images; local median for 2-bed rentals is 12" },
    { "field": "description", "detail": "57 characters of substantive content; no room detail" }
  ],
  "duplicates": {
    "cluster_id": "dup_01HXQ22",
    "members": 3,
    "canonical": "lst_2198441",
    "basis": ["address_match", "image_perceptual_match", "attribute_match"],
    "price_disagreement_pcm": [720, 1180, 1195]
  },
  "price_check": {
    "expected_pcm": 1180,
    "deviation_pct": -39.0,
    "flag": "implausibly_low_for_local_market"
  },
  "image_checks": [
    { "image": "a.jpg", "duplicate_of_listing": "lst_1904772", "similarity": 0.97 }
  ],
  "fraud_signals": [
    { "signal": "price_far_below_market", "weight": 0.34 },
    { "signal": "images_reused_from_other_listing", "weight": 0.31 },
    { "signal": "advertiser_registered_6_days_ago", "weight": 0.18 }
  ],
  "recommended_action": "hold_for_human_review"
}

Where the data comes from

Your listing feed	The listings as agents submit them, including the inconsistencies and the duplicates — which is the actual subject of this build
Address reference data	An authoritative address or property identifier dataset, which is what makes reliable duplicate detection possible; usually a licensed national dataset
Rental and sale price models	Expected price for the property, so a plausibility check compares against the local market rather than a flat threshold
Energy certificate registers	Published certificate data, which can fill a missing disclosure field rather than only flagging it
Listing images	Perceptual comparison across your own corpus; cross-portal image comparison depends on what other sources permit and is scoped accordingly
Your moderation history	Past decisions on duplicates, stale listings and suspicious advertisers, which are the training labels for the ranking

On data licensing. Being allowed to read a dataset does not automatically mean you may redistribute it, resell it through an API, or train a model on it. Before any build starts we check the licence, terms and derived-data rules of every source, and we design around the ones that do not permit your intended use. Where a commercial licence is required, that cost is identified during discovery rather than discovered later.

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.

Duplicate detection on a combination of resolved address, attribute agreement and perceptual image matching, because any one of the three alone produces both false merges and misses
Canonical-listing selection within a cluster on completeness, freshness and agent feed quality rather than arbitrary choice
Quality scoring with field weights derived from observed effect on search engagement, so the score reflects what actually matters rather than a checklist
Price plausibility against the local price or rent model with an interval, flagging deviation in both directions — an implausibly high listing is a data error, an implausibly low one may be fraud
Stale detection from listing behaviour, enquiry patterns and market signals, modelled as a probability rather than a fixed days-live rule
Fraud signals combined into a ranked review queue, never into an automated removal, with every contributing signal itemised for the reviewer
Calibration against your moderation outcomes, with precision tracked per signal so the weak signals can be identified and dropped
Monitoring on per-agent feed quality and on sudden changes in duplicate or missing-field rates, which usually indicate a changed agent system rather than changed behaviour

What it changes for the business

Cleaner search results

Deduplication and stale removal improve the thing users actually judge a portal on.

Better filter coverage

A specific list of missing fields per listing makes the quality conversation with agents actionable.

Fraud caught earlier

Reused imagery and implausible pricing surface within hours of publication rather than after a complaint.

Feed accountability

Agent-level quality aggregation turns a vague standards request into a measurable one.

How it fits into your product

How it embeds

Synchronous scoring at feed ingestion, so poor or suspicious listings can be held before publication
Batch scoring across the live inventory for backlog clearance and periodic audit
Duplicate cluster output your search index can consume directly, with a canonical listing nominated
Agent-facing issue lists, so the portal can tell an agency exactly what to fix on which listing
Review queue API for your moderation tooling, with an outcome endpoint that recalibrates ranking
Deployment inside your environment where agent and listing 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 weeks

Discovery 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

Will it automatically remove bad listings?

For duplicates and clear stale listings, automation is reasonable and we would build it. For fraud indicators, no — the signals are probabilistic and a wrongly removed listing costs you an agency relationship and possibly a legitimate landlord. The API holds and queues; a human decides. The recommended action field is a recommendation, not an instruction.

How reliable is duplicate detection?

Good where addresses resolve cleanly to an authoritative identifier, weaker for new-build developments where unit numbering is inconsistent and for listings that give only a street. The response reports the basis for each cluster so a reviewer can see whether the match rests on address, images or attributes, and genuinely ambiguous clusters are queued rather than merged.

Can you compare images against other portals?

Only where that source's terms permit collection and comparison, and many do not. Within your own corpus, image reuse detection is straightforward and catches a large share of rental fraud, since fraudulent listings commonly recycle photography already on your own site. We scope cross-portal comparison per source rather than assuming it is available.

Will agents object to quality scoring?

Some will, which is why the output is itemised rather than a bare grade. A listing marked poor with three named missing fields and a note that the local median photo count is twelve is a request an agency can act on. A score with no explanation becomes an argument, and we would build it the first way.

Can it detect that a property has already let?

It can estimate it from listing behaviour, enquiry patterns and market signals, as a probability rather than a fact. The only reliable source is the agent telling you, and no model replaces that. What it does well is rank which live listings are most likely stale, so the chasing effort goes to the right ones.

All Real Estate & Property offers →

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.

Discuss This Build Browse All Offers