Listing syndication is the job of getting a property from your own system onto a portal and keeping the two in step until the unit is let or sold. In Germany the portal that matters most is ImmobilienScout24, and there are exactly two ways to reach it: a file-based OpenImmo transfer, or the portal's own REST API. They behave differently, they fail differently, and most teams end up needing both, because IS24 is not the only portal on the media plan.
Route one: OpenImmo, the file that reaches most portals
OpenImmo is an open XML standard for German real estate data, maintained by the OpenImmo initiative. You describe each property once in a structured XML document, package it with its photos and documents in a ZIP, and drop that package into the portal's transfer folder, usually over FTP or SFTP. The portal collects the package on its own schedule and imports it.
Its strength is reach. Immowelt, Immonet and dozens of regional and specialist portals accept OpenImmo, so one export serves many destinations and adding a portal is mostly a matter of adding transfer credentials. The format carries create, change and delete through an action flag per property, supports full imports where the package is the whole truth and partial imports that carry only what changed, and bundles media inside the ZIP with the cover image and ordering declared in the XML.
Its weakness is timing. A file transfer is batch by nature: a price change lands at the portal's next import run, not at the moment you save it, and a withdrawn listing can stay visible for hours. For a portal you update daily that is acceptable. For the one portal where most of your inquiries originate, it usually is not.
Route two: the ImmobilienScout24 REST API
ImmobilienScout24 offers a proprietary REST API alongside file import. Instead of dropping a file, the connector makes direct calls: authenticate through OAuth, create or update the listing, upload each photo through a separate attachment call, then publish. Because every step is a request with a response, a change is live in near real time, an error comes back as a specific message rather than a silent non-import, and inquiries can be pulled back through the same interface.
The price is scope and setup. The API reaches IS24 only. It requires an application registration and access approval from the portal, token handling, and respect for rate limits. There is a sandbox endpoint for testing and a production endpoint for live listings, and a connector that cannot tell the two apart will publish test data to the public at some point. Treat the sandbox-to-production switch as a deliberate, logged act.
What a listing needs before it can go anywhere
Both routes reject or degrade a listing that is incomplete. The record needs its address and geocode, the marketing type (sale or rent), the object type, living and usable area, room count, the price or rent with the correct basis (kalt, warm, per square metre), and a media set with a defined cover image and order. In Germany the energy certificate is not optional: the Gebäudeenergiegesetz requires the certificate type, energy demand or consumption value, energy source and year of construction in the advertisement itself, and the portals enforce it. A listing pipeline that lets a listing reach the portal without those fields produces a compliance problem, not just a rejected upload.
The lifecycle: publish, update, withdraw
Syndication is not one push. It is a lifecycle with three transitions, and each one is where a manual process breaks.
- Publish. The record maps to the portal format and goes live. The portal returns an identifier and an exposé URL; both belong on your record, or you will never be able to find the listing again from your own system.
- Update. A price change, a new floor plan, a corrected area. Under OpenImmo this is a changed package at the next import; under the API it is an immediate call. Either way, the portal listing must never be edited by hand in the portal's own interface, because the next sync will overwrite it.
- Withdraw. The unit is let or sold. This is the transition teams forget, and a stale listing costs money twice: the portal keeps charging, and the inquiries keep arriving for something that no longer exists.
Leads come back, or the exercise was pointless
The reason to publish is demand, and demand arrives as contact inquiries. Each one should land on the record of the listing it came from, matched to the unit, with the prospect's search profile attached and consent logged at the moment of arrival, because the DSGVO applies from the first message. Two things go wrong here in practice. The same prospect writes about three units and becomes three records, so deduplication has to run on arrival, not in a quarterly clean-up. And an inquiry that lands in a shared inbox instead of the system is answered late or twice. If your portal connector only pushes and never pulls, half of the integration is missing.
What running it looks like day to day
A syndication process that is actually operated, rather than demoed, has a few visible properties. Every publish, update and withdraw is a job with a state: queued, processing, succeeded, or failed with the portal's own error text. Failed jobs are retried deliberately, not lost. Credentials for the portal live in a secrets store, not in a config table someone can export. There is one place to see which portals are connected, whether the connection is healthy, and what happened to the last fifty jobs. And the person publishing a listing does it from the property record, not from a second tool with a second login.
How REPM does it
REPM covers both routes from one property record. For ImmobilienScout24 it uses the official IS24 REST API: one click on Publish in the ListingCockpit creates the publication and a sync job, a durable outbox delivers it, and the exposé link is written back to the listing. Jobs show Queued, Processing, Succeeded or Failed with the portal's error text and a one-click retry. The Portal Hub handles the connection check, the OAuth certification with IS24, the active toggle and the job log, against the sandbox or the production endpoint, with credentials held in Azure Key Vault. For Immowelt and the long tail REPM exports OpenImmo 1.2.7. Inquiries return to the record deduplicated and with consent logged, matched to the unit and the search profile. If you want to see a listing go from record to portal URL on your own data, request a demo.