Property feeds explained, without the jargon.

The chain, in one line

Your negotiator enters a property into your CRM. The CRM produces a feed. That feed is collected by your website and, separately, by each portal. Nothing types the property in twice — everything downstream is a copy of what is in your CRM.

That last point matters more than anything else here. Your CRM is the single source of truth. If a detail is wrong on your website, the fix is almost never on the website.

Push and pull

There are two ways the data moves, and the difference explains most timing complaints.

• Pull (scheduled). Your website or the portal fetches a file on a timer — commonly every hour. Simple and robust, but a change made at 10:05 might not appear until 11:00.
• Push (real-time). Your CRM sends each change the moment it happens. Updates appear within a minute or two. This is what Rightmove's Real Time Data Feed does, and OnTheMarket and Openbrix support the same specification.

The formats you will hear named

You do not need to be able to read these. You do need to know which one you have, because it determines what is possible.

• BLM — Rightmove's bulk format, usually the V3 version. It became the closest thing the UK has to a standard, and most systems can produce or consume it. Bulk means the whole book of properties at once.
• RTDF — Rightmove's Real Time Data Feed. Individual properties sent as they change, rather than the whole set on a timer.
• Vendor XML and JSON — most CRMs also expose their own: Vebra API XML, Jupix XML, Expert Agent XML, DezrezOne XML, Rezi JSON, JET from Reapit, and 10ninety among others. These usually carry richer detail than BLM, so a website built against the native feed can show more than one built against a generic file.

The four things that actually break

In practice, nearly every feed complaint traces back to one of these.

1. Status changes lag. Under Offer and Sold STC are the usual suspects. If your website pulls hourly, expect up to an hour of delay — and check the status is being set in the CRM at all, rather than only mentioned in the description.
2. Images arrive in the wrong order, or not at all. Feeds carry images by position. If someone reorders photos in the CRM, some integrations do not detect it as a change and keep the old order. Very large files also time out during transfer, which is why a property will sometimes appear with nine of its twelve photos.
3. Branch mapping. Multi-branch agencies have a branch code in the feed that must match the code your website and each portal expect. Get it wrong and an office's properties silently vanish, or all appear under one branch.
4. Field mismatches. Property type, tenure and price qualifiers are picked from fixed lists that differ between systems. If your CRM offers a value the receiving system does not recognise, that property either fails to import or lands in the wrong category — which is why a flat occasionally shows up filed under bungalows.

Questions worth asking your provider

If you are choosing a website provider, or trying to work out why yours keeps going wrong, these five questions will tell you most of what you need.

• Which feed are you reading — the native CRM feed, or a generic BLM file?
• How often does it update, and is it push or pull?
• What happens when an import fails — does anyone get told, or does it fail quietly?
• Can I see a log of what came through and when?
• If we change CRM, what does the migration involve?

That fourth one separates the good providers from the rest. A feed with no monitoring will eventually break without anyone noticing, and you will find out from a vendor rather than from your website.

We connect to the systems listed above as standard. If you are not sure what you are running or why your listings keep misbehaving, send us your web address and we will take a look.