Real estate

Portal integration

Rightmove, Zoopla and OnTheMarket are the primary route by which an agency's stock reaches applicants, and each expects listing data in its own feed format, updated promptly enough that availability shown on the portal matches reality. We build the integration layer that generates RTDF and BLM feeds from a single internal property record, keeps listing status synchronised as it changes, captures enquiries from all three portals into the agency's own CRM, and suppresses the duplicate leads that naturally arise when the same applicant contacts the same property through more than one channel.

This work is usually the fastest-payback module in a property management platform build, because the failure modes it fixes — stale listings, missed or duplicated leads — are visible to prospective tenants and applicants immediately, and correcting them improves both conversion and the agency's reputation on the portals it depends on.

Talk to us Discovery sprint

The workflow this replaces

How portal listings and enquiries are handled without integration

Where feed generation and enquiry capture have not been built properly, most agencies run a manual or semi-manual process that degrades as stock volume grows.

Step 01
A new property is entered once in the management system, then again per portal
Details, photos and floorplans are entered into the core management system, then a member of staff logs into Rightmove's, Zoopla's or OnTheMarket's own listing interface separately to publish the same property, repeating data entry and introducing the risk of inconsistency between what each portal shows.
Step 02
Price and status changes are updated on one system and forgotten on others
When a property's price changes or it goes under offer, the core system is updated promptly because that is where the agency's own team works, but the corresponding update on each portal depends on someone remembering to log in separately and repeat the change, and that step is the one most often missed under time pressure.
Step 03
Portal rejections are discovered by a landlord noticing, not by the agency
A listing that fails a portal's validation — a missing EPC rating, too few photos — is silently rejected or held back, and the agency often only finds out when a landlord asks why their property isn't appearing on a portal they specifically asked to be listed on.
Step 04
Enquiries land in a shared inbox that has to be triaged manually
Portal enquiries arrive by email into a shared inbox, where a member of staff reads each one, works out which property and which negotiator it relates to, and manually creates or updates a lead in the CRM, a process that introduces delay between enquiry and first contact.
Step 05
The same applicant generates three separate, unlinked leads
An applicant who enquires via Rightmove, then Zoopla, then the agency's own website within the same hour appears as three unrelated entries in the CRM unless someone manually notices and merges them, and in the meantime two different negotiators may independently call the same applicant about the same property.

None of this requires bad practice from staff — it is the predictable result of treating portal publishing and enquiry handling as manual tasks layered on top of a system that was never built to automate either. The integration layer we build removes the manual steps without changing how the agency's team works day to day.

What we build

Modules in a typical portal integration build

Feed generation in RTDF and BLM

A generation service that reads the internal property record and produces RTDF for Rightmove and BLM for Zoopla, OnTheMarket and other consuming portals, from a single source of truth rather than duplicated entry.

Field validation before submission

Checks against each portal's mandatory field requirements — EPC rating, minimum photo count, address and price formatting — before a feed is submitted, catching gaps before a portal rejects the listing.

Listing status synchronisation

Near real-time propagation of price, status and availability changes from the core management system out to every connected portal, rather than a batch update run once or twice a day.

Rejection and error handling

Portal rejection responses captured and routed to a visible queue with the specific reason, so a data gap can be corrected and resubmitted within hours rather than discovered weeks later.

Enquiry capture into the CRM

Portal enquiry webhooks or scheduled retrieval feeding applicant details and the property enquired about directly into the CRM's applicant register, tagged by source portal, without manual re-keying from an inbox.

Duplicate suppression

Matching logic across contact details and property reference within a defined time window, linking repeat enquiries from the same applicant to a single lead record rather than creating separate, competing leads.

Integrations

Named systems and interfaces

Portals

RightmoveZooplaOnTheMarket

Feed formats

RTDFBLM

Management platforms

ReapitAltoJupixDezrezQubeMRI

CRM

Lettings CRM (ours or existing)email service providers

Where an agency already has a lettings CRM, enquiry capture and duplicate suppression are built to write into it directly through its API. Where the CRM is also being built by us, this integration is delivered as part of the same platform.

Data and compliance

Requirements written into the build

Property record fields required by portals: EPC rating and certificate reference, minimum photo count, floorplan, address formatting and price, validated before feed submission.
Feed refresh cadence: Status and price changes queued for near real-time push; full property re-validation run on a scheduled cycle to catch data drift.
Duplicate match window: Configurable per agency, typically enquiries from the same contact against the same property within 24 to 72 hours treated as a single lead.
Rejection error taxonomy: Portal-specific rejection reasons normalised into a common internal error list so staff see one consistent set of fix instructions regardless of which portal rejected the listing.

Architecture note

How the system is put together

Feed generation runs as an adapter layer per portal and per format, reading from a single internal property model, so a change to a portal's field requirements is isolated to its own adapter and does not risk breaking feeds to other portals.

Listing status changes are pushed through an event queue rather than a polling job, so an availability change is reflected on connected portals within minutes rather than waiting for the next scheduled batch run.

Enquiry ingestion normalises each portal's webhook or export payload into a common lead schema before it reaches the CRM, so duplicate suppression logic runs against one consistent structure regardless of source portal.

Rejection handling stores the raw portal response alongside the normalised error, so a support query to a portal's own technical team can reference the exact payload that was rejected rather than a paraphrase of it.

Timeline

Build phases in weeks

Discovery

Weeks 1-2

Review of current portal accounts, feed setup (if any), enquiry handling process and the CRM or management platform to integrate against.

Feed generation

Weeks 3-6

RTDF and BLM generation, field validation, and initial submission to each portal with error handling.

Listing sync

Weeks 7-9

Near real-time status and price synchronisation, and rejection queue with visible error resolution workflow.

Enquiry capture and duplicate suppression

Weeks 10-13

Enquiry ingestion from all connected portals into the CRM, source tagging, and duplicate matching logic.

Pilot and rollout

Weeks 14-15

Pilot against a subset of live listings, validation of portal acceptance rates, then full portfolio cutover.

Indicative cost

Budget bands, not quotes

Discovery and scoping: £10,000 to £20,000, credited against the build.
Feed generation and listing sync for three portals: £180,000 to £280,000.
Full integration including enquiry capture and duplicate suppression: £250,000 to £380,000.
Managed run: Monthly retainer covering portal format changes and monitoring, priced after go-live scope is confirmed.

Bands assume integration with three major portals and one core management platform. Additional portals or software vendor feed formats can generally be added incrementally once the adapter architecture is in place.

Where this sits

Questions

Frequently asked

What is the actual difference between RTDF and BLM, and does it matter which we use?

RTDF (Rightmove Transport Data Format) is Rightmove's own XML-based feed specification; BLM (Bulk Load Module) is the format used more widely across Zoopla, OnTheMarket and a number of other portals and software vendors. The two formats overlap heavily in the property attributes they carry but differ in field naming, structure and how they represent media and floorplans, so a feed built for one cannot simply be relabelled for the other. We build a generation layer that produces both from a single internal property record, so the choice of format per destination is a configuration detail, not a rebuild.

How do you prevent a property being rejected by a portal without anyone noticing?

Feed generation includes validation against each portal's mandatory field requirements — a valid EPC rating, a minimum number of photos, correctly formatted price and address fields — before submission, and we capture and surface any rejection response the portal returns, routing it to a visible error queue rather than a silent failure, so a missing field gets fixed within hours rather than being discovered when a landlord asks why their property isn't showing.

How does duplicate suppression work when the same applicant enquires through three portals?

Enquiries are matched on a combination of applicant contact details (email, phone) and the specific property enquired about within a defined time window, and where a match is found, the later enquiries are linked to the existing lead as additional contact points rather than created as separate, unworked leads, so a negotiator sees one applicant record with three points of interest, not three records to divide between staff.

Can listing sync push availability changes back to the portals within minutes?

Yes, this is one of the more time-sensitive parts of the integration. When a property's status changes to under offer, let or withdrawn in the core management system, the update is queued for portal sync immediately rather than on a batch schedule, because a portal continuing to advertise an unavailable property for hours generates enquiries the agency then has to decline, at real cost to its reputation with prospective tenants.

Do you handle portal enquiry capture into our CRM automatically?

Yes. Portal enquiry webhooks or, where a portal does not offer one, scheduled retrieval, feed the applicant's details and the property they enquired about directly into the CRM's applicant register, tagged with the source portal, rather than arriving in a mailbox that has to be manually triaged and re-keyed.

What does a portal integration project typically cost?

A feed generation and listing sync build covering Rightmove, Zoopla and OnTheMarket, integrated with an existing management platform, typically runs £250,000 to £380,000 over three to five months. Adding enquiry capture and duplicate suppression as part of the same programme adds to the upper end of that range rather than requiring a separate engagement.

Tell us what your systems are doing wrong.

Send the problem, not a brief. We will tell you whether it is a project we should be involved in.

Talk to us