The short answer: one system of record, three channels (architecture in brief)
One rule governs the architecture: your CRM is the single system of record for every listing and lead, and Bayut, Property Finder and your own website are channels fed from it — never separate databases. A listing is created once in the CRM, validated there, and syndicated to both portals and your website. Enquiries flow back into the same CRM, deduplicated and routed to the listing agent. The Trakheesi permit number sits on the listing record, so it travels with every feed automatically.
The problem: four copies of every listing, none of them current
In many Dubai agencies the same apartment exists four times: on Bayut, Property Finder, the agency website and a spreadsheet. Each copy is typed and edited by hand. A unit sells on one channel and stays advertised on another. A price changes in the CRM and never reaches the portals. A portal lead lands in an agent's inbox, outside the pipeline, and no manager can see if it was answered. The permit number is copied separately onto each version, so an expired or mistyped permit can sit on a live listing unnoticed. This is an architecture problem, not a people problem. Four copies of the truth will always drift; one record, published everywhere, cannot.
How portal feeds actually work: XML syndication vs direct API
Portals accept listing data in two ways. The established route is XML syndication: your system generates a structured XML file of listings in the portal's format; the portal collects it on a schedule, validates it, and publishes what passes. Updates travel at the feed's refresh rhythm, so a price change appears when the next file is processed, not instantly. The second route is a direct API connection: an interface your system calls to create, update and withdraw listings and receive status back. API connections can be faster and return richer errors, but access depends on partner terms, account type and technical approval. Many agencies run a mix — one portal on XML, another on API — which is why the feed layer should sit behind your CRM. Confirm current options in each portal's official partner documentation before scoping, because they change.
Outbound: listings from your CRM to Bayut and Property Finder (fields, photos, validation)
Outbound syndication succeeds or fails on field discipline. A listing must be mapped field by field from your CRM to each portal's required structure: property type, location and community, price, bedrooms, bathrooms, size, furnishing, amenities, description, and agent details. Photos need the same discipline — order, resolution and count affect how a listing presents. Validation is the gate that matters: listings with missing fields, invalid values or broken image references are rejected, sometimes quietly. A sound build validates inside the CRM before anything is sent, applying the portal's own rules, and surfaces every rejection as a named, fixable error rather than a silent absence. Our real estate website development work starts from this same record-first principle.
The permit layer: Trakheesi numbers travelling with every listing
Every Dubai property advertisement must carry a valid Trakheesi permit number, issued through the Dubai Land Department's Trakheesi system under RERA's rules; since April 2023 permits also carry the Madmoun QR code that lets anyone verify the advert. Portals require the number before a listing goes live, and your own website is an advertising channel too. In an integrated build, the permit is a validated field on the CRM record, checked before the feed is generated, and carried into every outbound version — all channels publish the same number because they publish the same record. Expiry belongs in the same layer: a lapsed permit should flag for renewal or withdraw the listing from syndication. Confirm current requirements against Dubai Land Department guidance, since the authority sets the rules and they change.
Inbound: portal leads into the same CRM — routing and dedupe by phone
The return journey matters as much as the outbound feed. A portal enquiry should arrive in your CRM as a lead attached to its listing — not as an email an agent may never forward. Two mechanics decide whether this works. The first is routing: each lead is assigned by rule, normally to the listing's agent, with a fallback to a duty queue, so no enquiry waits on one inbox. The second is deduplication: the same person often enquires about three properties on two portals in one evening. Matching on the phone number — the most stable identifier in UAE enquiries, with email as a secondary check — merges those enquiries into one contact with three listing interests, instead of three leads that competing agents chase separately. Attribution stays accurate because the first producing channel is preserved on the merged record. Lead data is personal data, so handling should follow the UAE Personal Data Protection Law (Federal Decree-Law No. 45 of 2021): collect what follow-up needs, control access, and honour deletion requests.
Your own website as a channel, not a brochure (listings on your domain, SEO, lead capture)
Once listings live in one CRM record, your website becomes a fourth channel fed by the same system. Every listing publishes on your domain with its own page, current price, the same photos the portals show, and the permit number alongside. Enquiries from your own site carry no per-lead portal cost and arrive with full context in your CRM. And listing pages on your domain are the one channel you fully control — they can rank for community and building queries instead of renting visibility from a portal. The patterns behind this are covered in our guide to real estate website design and development and our article on developer property portal websites. Agency visibility is a separate discipline, explored in GEO for real estate.
Feed health: rejection handling, sync status, stale-listing alerts
An integration is finished not when the first feed succeeds, but when failures become visible. Three habits separate a dependable setup from a hopeful one. First, sync status per listing and per portal: whether each channel accepted the property, when it last updated, and whether it is live now. Second, rejection handling as a workflow, not a log file: every rejection lands in a queue with the reason translated into a fixable instruction, and someone owns clearing it. Third, stale-listing alerts: a listing marked sold or leased that is still live on any channel after the next sync cycle gets raised — it wastes enquiry spend and creates compliance exposure. Scope these views from the start; retrofitting them means rebuilding the feed layer you already paid for.
Build scope and cost drivers (what moves the quote; competitor benchmark range labelled as such)
A feed-integration scope normally contains five blocks: the listing record and field model in the CRM, the outbound connection for each portal, validation and rejection handling, the inbound lead flow with routing and dedupe, and the feed-health views above. The quote moves with the number of portals, XML versus API connections, the condition of your listing data, and how much history must be cleaned and migrated. For market context only: OXEDGE, a Dubai competitor, publishes AED 40,000–120,000 for an agency website with CRM and portal sync within a wider platform build — a competitor's range for a broader scope, not WebStackRank pricing; no verified WebStackRank price exists for this build type. The nearest verified WebStackRank anchor is custom web application development, from USD 3,500 (approximately AED 12,854, AED labelled approximate) — a starting price for a typical small-business scope, with the final fixed quote after a scoping call. Terms: 50% deposit to begin, 50% at launch, full ownership on final payment.
Decision criteria: plugin/CRM-native sync vs custom integration
You have three realistic routes. If your current CRM already offers maintained Bayut and Property Finder syndication and your volumes are standard, use the native route first — the fastest, cheapest way to one system of record. If your CRM syncs listings but cannot dedupe leads, carry permits as validated fields, or show sync status, a middleware layer may close those gaps without a rebuild. A custom integration earns its cost when gaps are structural: multiple branches or brands feeding the same portals, approval workflows before a listing may advertise, heavy lead volumes, or a website that must behave as a full listings channel. The test is which route gives you one record, visible feed health and clean lead data at your actual volume.
Common mistakes
The most common mistake is integrating the website and portals separately, so the CRM never becomes the record and drift continues with better graphics. Second is treating the permit number as advert copy instead of record data. Third is celebrating outbound syndication while leaving inbound leads in inboxes. Fourth is skipping pre-send validation, so rejections accumulate silently and listings the team believes are live are not. Finally, agencies scope the build but not the ownership: nobody checks the rejection queue, and within a quarter the feeds are as untrusted as the spreadsheets they replaced.
FAQ
Does my CRM need an API connection, or is an XML feed enough?
For many agencies, yes: listings publish reliably and updates travel at the feed's rhythm. An API connection is worthwhile when you need faster updates, automatic per-listing status, or tighter rejection handling. The answer depends on what each portal offers your account type, so confirm options in the portals' partner documentation during scoping.
Where should the Trakheesi permit number live in the system?
On the listing record in your CRM, as a required, validated field. Stored there, it flows to Bayut, Property Finder and your website automatically, expiry is flagged centrally, and no advert can be generated from a record that lacks a permit.
How does lead deduplication by phone actually work?
When a lead arrives, the CRM checks the phone number against existing contacts before creating anything new. A match merges the enquiry into that contact, adds the listing interest, and preserves the original source for attribution. Email is a secondary check. The result: one conversation history per person, however many portals they used.
Can my own website really compete with the portals for enquiries?
Not by replacing the portals, but by owning one channel outright. Your site can rank for community and building searches, present your full stock without competitors beside it, and capture enquiries at no per-lead portal cost.
What happens when a portal rejects some of my listings?
It shows exactly which listings were rejected and why, in a queue your team works through — a missing field, an invalid category, a photo problem. Without that visibility, rejections are silent: the listing never appears, and the team learns of it from a client's complaint.
Scope your portal integration (CTA)
If your listings live in four places and your leads live in inboxes, the fix is architectural. It starts with a scoping call: which CRM you run, which portals you feed, where permits and lead data sit today. WebStackRank scopes integrations like this as fixed-price custom application work, with an itemised proposal before commitment and no retainer required. Talk to us about custom web application development or via our contact page.
