A property disappearing from a portal just after instruction is not a minor technical annoyance. It can mean missed enquiries, an unhappy vendor or landlord, and staff logging into several systems to work out what changed. Effective property feed error troubleshooting starts by identifying where the listing stopped moving, rather than correcting details in every portal and hoping for the best.
For most agencies, a portal error is not actually a portal error. It is usually a data issue in the CRM, a mismatch in the feed format, a missing mandatory field, or an account setting that prevents publication. The quicker you isolate that point of failure, the quicker the property is back in front of buyers and tenants.
Start with the property status, not the error message
A rejected listing may produce a clear message such as “invalid postcode” or “missing price”, but many feed issues are less obvious. A property can appear active in your CRM while being excluded from export. It can be accepted by a feed platform but held by a portal because the branch identifier, listing type or media does not meet that portal’s rules.
Check the listing’s journey in order. First, confirm it is marked live, available and eligible for export in the source system. Next, check whether it appears in the latest XML, BLM, API or RTDF feed import. Then confirm whether the feed processor accepted it for the intended portal. Finally, review the portal account or portal validation report.
This sequence matters. If the property is not leaving the CRM, changing the portal record achieves nothing. If it has left the CRM but failed validation, the correction belongs in the source data. Keeping one reliable source of truth prevents the familiar cycle of a portal edit being overwritten by the next feed import.
The common causes of property feed errors
Most feed problems fall into a small number of categories. Knowing them helps your team investigate with purpose rather than spend an hour clicking through dashboards.
Missing or invalid mandatory data
Portals have their own required fields, and those requirements can differ between sales, lettings, commercial and overseas listings. A missing address, postcode, price qualifier, tenure, council tax band, EPC information or property type can block a listing. In lettings, the available date, deposit, furnishing status and rental frequency are frequent causes of rejection.
The practical fix is to review the field in the source system, not merely the text shown on the property particulars. A value might look correct to a person but be sent in a format the portal does not accept. For example, an unsupported property type, a price entered with non-standard characters, or a postcode with an extra space may fail validation.
Incorrect branch, office or portal mapping
Multi-branch agencies often need separate portal account identifiers for each office. If a branch is mapped to the wrong account, the portal may reject the property, show it under the wrong office, or leave it unpublished.
This is particularly relevant after an acquisition, office move, CRM change or new portal subscription. Check the branch code in the source data and the account mapping in the feed setup. Also make sure the destination portal account is active and has the correct advert allowance. A technically perfect feed cannot publish into an expired or restricted portal account.
Media failures and image rules
Images cause more problems than they should. A listing may be held because photographs have not completed upload, an image URL is inaccessible, the file is too large, or the first image does not meet the portal’s quality rules. Floorplans, EPC documents, virtual tours and brochures can fail for similar reasons.
Before replacing every image, establish whether the issue affects one property or the whole feed. One affected property usually points to its individual media files or URLs. Dozens of missing images often indicate a wider website, CDN, CRM or permission issue. That distinction saves time and prevents unnecessary rework.
Feed format or integration changes
An XML, BLM or API feed depends on consistent field mapping. If a CRM provider updates a field name, changes an endpoint, rotates credentials or alters how it supplies images, a previously healthy connection can begin sending incomplete data. New property software integrations can create the same issue if testing has focused on a single listing type.
Watch for patterns. If only new-build properties fail, compare their data structure with standard resale listings. If sales are live but lettings are not, inspect lettings-specific fields and portal settings. A problem that starts at exactly the same time across multiple branches is more likely to be an integration or import issue than staff input.
A quick workflow for property feed error troubleshooting
Speed matters when a property is due to launch, but rushing to apply random fixes creates duplicate listings and confusing audit trails. Use a short, repeatable process.
First, note the property reference, branch, portal, listing type and time of the last successful update. These details let support teams find the exact transaction quickly. A portal listing reference is useful too, especially where a property has been withdrawn and reactivated.
Second, compare the source record with the last accepted feed record. Look for changed fields rather than reading every detail from scratch. The new price, status, address, property type, image, branch or availability date is often the answer.
Third, read the full validation message and classify it: source-data error, feed-mapping error, portal-account error or media error. Do not treat “rejected” as the diagnosis. It simply means the portal has not published the record.
Fourth, correct the data once, in the system that owns it, then wait for the next scheduled import or request a refresh where available. Repeatedly saving a listing can create unnecessary updates, while editing directly on a portal can be overwritten minutes later.
Finally, check that the correction has travelled all the way through. A successful feed import does not always mean the listing is already visible to the public. Portals may have their own processing time, moderation rules or overnight checks. For launch-critical stock, confirm the live public advert as well as the feed status.
Avoid the fixes that create bigger problems
The most costly response to a feed error is manually rebuilding the property on every advertising channel. It feels quick in the moment, but it creates duplicate adverts, mismatched prices, different descriptions and a difficult clean-up later. It also removes the main benefit of feed distribution: one update should reach every destination.
Similarly, do not delete and recreate a listing unless there is a clear reason. A new portal record can lose advert history, saved-property activity or established search placement. Where a property has a valid portal identifier, correcting and republishing the existing record is usually the better route.
There is one exception. If an old listing has been permanently withdrawn and then returns to market after a substantial gap, the portal may require a fresh record under its own rules. This is a portal-policy decision, not just a technical one, so check before actioning it.
Build checks into the day-to-day process
Good property feed error troubleshooting becomes much easier when errors are caught before a portal does. Create a simple pre-publication standard for negotiators and administrators: complete the mandatory property fields, add approved photography, select the correct branch and listing type, and confirm the status is exportable. The goal is not more administration. It is fewer preventable corrections at 5pm on a Friday.
For agencies with frequent stock movement, review import reports at regular intervals. Fifteen-minute import checks are particularly useful for new instructions, price reductions, offers agreed and let agreed updates. They reveal whether the issue is isolated or systemic while there is still time to act.
A central feed dashboard also gives managers a clearer view across branches and portals. Instead of asking each office whether its listings are live, they can see exceptions, rejected records and recent updates in one place. That is operational control, not just technical convenience.
Estate Agent Feeds is built for this practical reality: send property data to the portals you need from one place, whether your data arrives through XML, BLM, API, Jupix, Vebra or manual entry. When an issue needs a human answer, direct phone and email support helps avoid the no-reply-ticket routine that can hold up a launch.
When to escalate a feed problem
Escalate promptly if a whole branch disappears, every new property fails, images vanish across multiple listings, or the feed stops importing altogether. Send the property reference or a small sample of affected references, the portal name, the time the issue began and any validation message. This gives the technical team enough information to trace the failure without several rounds of questions.
For a single rejected record, first confirm the source data and recent changes. For a broad failure, avoid making large-scale manual edits until the cause is understood. A mapping correction or account change can restore hundreds of listings far more safely than manual intervention.
The best outcome is not simply fixing today’s missing advert. It is setting up a clear route from your property system to every portal, with data checked early and a real person available when something changes. That keeps your team focused on instructions, viewings and deals, while your listings keep moving.