International Listing Syndication: A Practical Guide for Agencies

Published on: August 19, 2026

Last verified: 19 August 2026. Portal specifications, national advertising requirements and data protection obligations change; confirm current requirements with each destination.

Quick answer: Syndication fails the same dozen ways every time. There is no universal international listing format, so assume every destination needs its own mapping. Most failures are not in the XML but in the field mapping, above all area fields, property type taxonomy and reference IDs, and in photographs whose URLs are unstable, hotlink-protected or served over HTTP. Publish a full snapshot atomically with a count check, because in most implementations a listing missing from the feed means delete. Then close the loop: an authenticated, idempotent lead webhook routed to a person who reads the enquiry's language.

Most agencies discover syndication the same way. Someone asks for a feed, the CRM vendor says it can produce one, a URL gets emailed, and three weeks later a colleague notices that half the portfolio is missing from the destination site, the prices look wrong in one currency, and every photo is a grey placeholder.

None of that is exotic. It is the same dozen failures every time, and they are all preventable if you understand what a listing feed actually is and where it breaks. This guide is written for the agency principal who has to make the decision and for the developer or CRM contact who has to implement it.

What syndication is, in one paragraph

Syndication is the automated republication of your inventory on someone else's site. Instead of a person retyping each property, a machine-readable file or endpoint describes your listings and a destination system reads it on a schedule. Your CRM stays the single source of truth. Everything downstream is a copy that refreshes.

That last sentence is the whole discipline. The moment a portal's copy stops matching your CRM, you are advertising properties you do not have and hiding properties you do.

The three integration models

Feed pull. You publish a file, usually XML, at a stable URL. The destination fetches it on a schedule, typically every few hours to once a day. This is the dominant model in international property distribution because it requires the least from both sides. Your obligations are to keep the URL stable, keep the file valid, and regenerate it reliably.

Push via webhook or API. Your CRM posts changes to the destination as they happen. Updates are near instant and you never publish your whole portfolio as a public file. It costs more to build and requires retry handling on your side, because a failed post that nobody retries is a listing that silently never appears.

Manual or spreadsheet upload. Viable below roughly fifty listings, or for a pilot. It stops being viable the moment prices or availability change weekly, which is when the discrepancies start.

Most agencies begin with a feed pull and add a webhook later for leads coming back in the other direction. That combination, feed out and webhook in, covers the majority of real world requirements.

Choosing where to syndicate

More destinations is not better. Every destination is an integration you must monitor, and a stale listing on a portal you forgot about does more brand damage than not being there.

Sort candidates into three types.

The domestic hub. The one portal that a local buyer in your market actually uses. Usually non-negotiable, usually the most expensive, and usually not where your foreign buyers are.

International and language-specific portals. These reach buyers searching from another country, often in another language. Their value depends entirely on whether your inventory matches what their audience is looking for. A portal with heavy northern European traffic is worth a great deal to a coastal agency and almost nothing to a city-centre commercial specialist.

Aggregators and syndicators. Intermediaries that take one feed and distribute it onward. Efficient, but ask the question that matters: after your listing is republished twice, who receives the enquiry, and what do they do with it?

Before signing anything, get written answers to these six:

1. Who receives the enquiry, and does it come to us with the buyer's contact details or is it held?
2. Are our agency name and contact details displayed on the listing, or replaced?
3. Can the destination republish our listings to third parties, and can we see the list?
4. How quickly is a removed listing removed downstream? Ask for hours, not "promptly".
5. What is the commercial model: subscription, per lead, per listing, or commission share?
6. Who is the controller and who is the processor for enquiry data, and is there a data processing agreement?

Question three is the one agencies skip and later regret, when a listing turns up on a site they have never heard of with someone else's phone number on it.

Feed formats: there is no universal standard

There is no single international listing format, and anyone who tells you otherwise is describing their own. In practice you will meet a handful of families:

• Portal-specific XML schemas. Most large portals publish their own specification and validate strictly against it. Overseas property distribution has a few widely reused XML schemas that many smaller destinations have adopted precisely because they were already implemented in common CRMs.
• National standards. Germany's OpenImmo XML is the closest thing to a genuine national standard, supported by most German-speaking systems. France runs largely through distribution intermediaries that accept a common upload and fan out.
• North America. Listing data flows through MLS systems, with the RESO Data Dictionary and Web API as the modern standard, replacing the older RETS approach. This is a materially different world with membership, licensing and display rules attached.
• UK. Historically the BLM format, with the major portals now operating their own real-time data feed specifications.

Practical consequence: assume every destination needs its own mapping, and build your export so that adding a destination means adding a transformation rather than rewriting your data model. If your CRM can only emit one fixed format, that is a constraint on your distribution strategy, and it is worth knowing before you sign a three-year CRM contract.

Field mapping is where the real work is

Producing valid XML is easy. Producing XML that means the same thing on the other side is not.

Property type taxonomy. Your CRM has "villa", "finca", "townhouse", "duplex", "chalet". The destination has eight categories. Whatever you do not map explicitly gets mapped to "other", and "other" is invisible in every filtered search. Map every type you use, including the ones you use twice a year.

Area, the single biggest source of error. Decide which of built area, usable area, terrace area, and plot area each field represents, and confirm what the destination expects. Then handle units: square metres, square feet, and in some markets local units entirely. A number without a unit is not data. Sending plot area into the built-area field makes a modest apartment look like a mansion and destroys buyer trust when they arrive. Our explainer on built versus usable area in a foreign listing covers what the buyer on the other end is actually reading.

Price. Specify the currency explicitly, per listing, not as a global assumption. Establish whether the figure includes or excludes transfer taxes, VAT on new build, and community charges. Decide how "price on application" is expressed, because a zero or an empty element is frequently parsed as a free property and sorted to the top of a cheapest-first search.

Reference IDs must be stable and unique. The destination uses your reference as the key. If your CRM regenerates references when a listing is edited, every edit creates a duplicate listing and orphans the original. If two branches can issue the same reference, one overwrites the other. Prefix by branch if you have to.

Status lifecycle. Available, reserved, under offer, sold, withdrawn, expired. Agree what each maps to and, critically, what a destination does when a listing disappears from the feed entirely. In most implementations, absence means deletion, which is the correct behaviour and also the reason a partially generated feed can wipe your portfolio.

Location. Country, region, town and district need to match the destination's own geography, or your listing lands in a fallback bucket. Coordinates should be accurate enough to be useful and imprecise enough to respect the vendor's privacy where that is the local norm. Decide the policy once, apply it everywhere.

Energy rating and legal identifiers. Several markets require an energy performance rating or a licence or registration number to be displayed in the advertisement itself. Where that is the case it is not an optional field, and a missing value can make the advertisement non-compliant rather than merely incomplete.

Photos and URLs: the most common failure of all

Photographs cause more syndication failures than every other field combined.

• URL stability. If your image URLs contain a session token, an expiring signature, or a timestamp that changes on regeneration, the destination will fetch them once and serve broken images afterwards. Image URLs must be stable and publicly reachable without authentication.
• Hotlink protection and user-agent filtering. Many CDNs block requests without a browser referer or with an unfamiliar user agent. Your images look fine to you and return 403 to the fetcher. Test with a plain command-line request from outside your network, not with your browser.
• HTTPS and mixed content. Serve everything over HTTPS. Insecure image URLs are dropped by many destinations outright.
• Ordering. The first image is the search-result thumbnail and determines almost all click-through. Confirm whether the destination honours your order or sorts by filename, and if it sorts by filename, name your files accordingly.
• Resolution and aspect ratio. Below the destination's minimum, images are rejected silently. Extreme aspect ratios are cropped centrally, which decapitates every vertical shot.
• Watermarks. Heavy watermarking is rejected by some destinations and looks unprofessional on all of them. A discreet mark in a corner is the practical compromise.
• Volume. Twenty-five good photographs beat sixty repetitive ones. Include a floor plan if you have one; it measurably increases enquiry quality.

Multilingual listings without embarrassment

If your buyers are foreign, your listing has to read naturally in their language. Machine translation is now good enough to be a starting point and not good enough to be the finished product for a high-value asset.

Rules that hold across every market:

• Never translate proper nouns. Street names, town names, development names and your own agency name stay as they are. Automated pipelines that translate "Calle Mayor" into "Main Street" produce addresses that do not exist.
• Never translate reference codes, units of measurement labels, or legal identifiers.
• Write titles as patterns, not sentences. Structure such as type, bedrooms, defining feature, location travels intact across languages. Idioms and wordplay do not.
• Declare the language of each description explicitly where the destination supports it, so it is served to the right audience rather than guessed at.
• UTF-8 throughout, end to end. Accented characters that survive your database and break in the feed usually indicate an encoding declared in one place and not another.
• Have a native speaker review the first thirty listings per language. After thirty you will know your recurring errors and can fix them at the template level.

Update cadence, and the failure that deletes everything

Decide between two models and implement one properly.

Full snapshot. Every generation contains your complete current portfolio. Simple, self-healing, and dangerous in one specific way: if generation fails halfway and publishes a truncated file, the destination sees the missing listings as deletions. Guard against this by generating to a temporary file, validating it, checking the count against the previous run, and only then moving it into place. A run that produces 40 percent fewer listings than yesterday should fail loudly rather than publish.

Deltas. Only changes since the last run. Lighter, but state can drift, and drift is invisible until someone complains. If you use deltas, schedule a periodic full reconciliation.

Whichever you choose:

• Publish a generation timestamp inside the file so the destination can detect a stale feed.
• Serve correct Last-Modified or ETag headers.
• Keep the URL stable for the life of the relationship. Changing it silently is the second most common cause of a portfolio vanishing.
• Monitor from outside your own network. Set an alert if the feed is older than expected or the listing count moves more than a set threshold.
• Log what the destination fetched and when. When a dispute arises about whether a price update was sent, logs settle it in a minute.

Getting leads back: the webhook side

Distribution is only half the loop. An enquiry is worth nothing if it lands in an inbox nobody reads at 03:00 local time.

For an inbound webhook from a portal into your CRM, specify:

• Payload contents. Buyer name, contact details, message, the listing reference, the source portal, the enquiry language, and a timestamp with an explicit time zone offset.
• Idempotency. Every delivery should carry a unique event ID, and your endpoint should ignore repeats. Retries are normal, duplicate leads in the CRM are not.
• Retry behaviour. Ask what happens when your endpoint is down. If the answer is "the lead is lost", that is a commercial risk, not a technical detail.
• Authentication. A shared secret or signature on the request. An open endpoint accepting anything will be found and filled with junk.
• Attribution that survives. Store the source on the contact record permanently. Without it you cannot tell which channel is producing buyers rather than noise six months later.

Then handle the human layer, which our guide to cross-border lead routing across time zones, languages and currencies covers in detail. An enquiry in a language nobody in the office reads is functionally the same as an enquiry that never arrived.

Pre-launch checklist

• Feed validates against the destination's published schema
• Every property type in your CRM maps to a real destination category
• Area fields mapped correctly, with units declared
• Currency declared per listing; price-on-application handled explicitly
• References unique, stable, and branch-prefixed if needed
• Status values mapped, and deletion behaviour understood
• Images publicly reachable over HTTPS, tested from outside your network
• First image is the intended hero image
• Descriptions reviewed by a native speaker in each target language
• Generation is atomic, validated, and count-checked before publishing
• Monitoring alerts on feed staleness and count anomalies
• Lead webhook authenticated, idempotent, and routed to a person
• Contract answers all six commercial questions above

Measuring whether it worked

Listing views are a vanity metric. Track, per destination and per month: enquiries received, the proportion that were contactable, the proportion that progressed to a viewing, the language of enquiry, and the average time from enquiry to first response by your team. That last one is usually the number with the most improvement available, and it costs nothing to fix.

Give any new destination two full quarters before judging it. International buyer cycles are long, and a channel that produces nothing in month one can produce a completion in month seven.

Frequently asked questions

Is there a single international standard we can build once and reuse?
No. Germany's OpenImmo and North America's RESO Data Dictionary are real standards within their own markets, but there is no global equivalent. Build a transformation layer per destination rather than one fixed export.

Half our portfolio disappeared from a portal overnight. What happened?
Almost always one of three things: the feed URL changed, a generation run failed and published a truncated file, or references were regenerated so the destination treated old listings as deleted and new ones as duplicates. Check the count in the last successful file first.

Our images work in the browser but show as placeholders on the portal. Why?
Hotlink protection or user-agent filtering at your CDN. Test the exact image URL with a plain command-line request from outside your network and look for a 403.

Should we translate descriptions automatically?
Use machine translation as a first draft, never as the published text for a high-value listing, and never let it touch proper nouns, reference codes or legal identifiers.

How many portals should a small agency be on?
Fewer than most start with. Each destination is an integration to monitor, and a stale listing damages you more than an absent one. Start with the domestic hub plus one international destination matched to your actual buyer nationalities.

Keep reading on JanusHermes

If you are looking at international distribution, JanusHermes accepts standard XML feeds with field mapping handled on our side, and supports CRM webhooks for enquiries flowing back to you. Details are on the agencies page.

On the commercial side of the same question, see small agencies versus portals, the leading property portal in each country and cross-border lead routing. On what international buyers actually check in a listing, read built versus usable area and how to spot AI-staged listing photos.

This article is general technical and commercial guidance as at August 2026 and creates no advisory relationship. Portal specifications, national advertising requirements and data protection obligations change; confirm current requirements with each destination and with your own legal adviser. JanusHermes accepts no liability for actions taken based on this content.

Standards referenced: OpenImmo XML (Germany); the RESO Data Dictionary and RESO Web API, and the legacy RETS specification (North America); the BLM format and current portal-specific real-time feed specifications (United Kingdom); and individual portal XML schemas published by their own operators.