Integration

Bayut, and the same flat listed twice

A Bayut integration brings your own listings into a Telegram bot for buyer matching. Because most UAE brokerages list on both Bayut and Property Finder, the specific problem here is deduplication — the same property arriving from two feeds with different references must alert a buyer once.

Bayut integration: auth, limits and availability

Auth model: API key
Listing references: Issued per portal; Bayut and Property Finder ids do not correspond
GCC availability: UAE core market — dual listing with Property Finder is the norm
Data flow: 5 hops, worker-mediated

As of 2025-10-01, Telegram Bot API 13.4

Why this integration exists

Bayut and Property Finder are both standard in the UAE, and most brokerages of any size list on both. That is a sensible commercial decision and it creates a data problem for any system consuming both feeds: the same physical property appears twice, with different portal references, occasionally different photographs, and sometimes a slightly different price because one feed was updated first.

For buyer alerts this matters immediately. A buyer registered for two-bedroom apartments in a specific tower should hear about a new listing once. Receiving the same flat twice within a minute, with two different reference numbers, makes the bot look broken and makes the brokerage look disorganised — and it is the first thing anyone notices.

Deduplication cannot rely on portal references because each portal issues its own. What works is a composite identity from the attributes that do not change between feeds: building or community, unit number where present, bedroom count, size and price band. Where that produces an ambiguous match, holding for review beats guessing, because merging two genuinely different units is worse than showing an agent two records to reconcile.

How the data actually moves

Deduplication happens before matching, so a property listed on both portals produces one record and one alert rather than two of each.

As with the other portal, the integration authenticates to whatever system holds your inventory rather than to Bayut directly — a listing manager, a brokerage CRM, or a scheduled feed. Credentials are Worker secrets, and the feed source is recorded on every listing so a discrepancy can be traced to the portal it came from.

Auth model: API key

Their limits, and what they mean for you

Portal listing references are issued per portal and do not correspond between them.

Deduplication uses a composite identity from stable attributes rather than references. Matching on reference guarantees every dual-listed property is treated as two.

The same property can carry different prices in two feeds if one was updated first.

The most recently updated record wins, and the discrepancy is logged. A price difference between portals is usually a sync lag and occasionally a genuine error worth an agent seeing.

Dubai advertising rules require a RERA permit number, which appears in both portals' data.

The permit is a useful secondary deduplication signal as well as a compliance requirement, since the same property carries the same permit on both portals.

Feed update frequency differs between portals and between listing systems.

One feed leads the other by minutes or hours. Alerting on first sight rather than waiting for both is correct; recording which feed it came from is what makes a later discrepancy explicable.

How it fails, and what happens when it does

A buyer receives the same property twice within a minute.

Deduplication failed or ran after matching. It is the most visible failure in a dual-portal setup and the first thing a buyer mentions.

Two genuinely different units in one building are merged.

Composite matching was too loose. Ambiguous matches are held for agent review rather than merged, because an incorrect merge hides a property from every buyer looking for it.

A price alert fires because two feeds disagree rather than because the price changed.

Price changes are confirmed against the same source before alerting. Otherwise buyers are told about reductions that never happened.

One feed stops and inventory appears to halve.

Per-feed staleness alerts. Without them a stalled feed looks like a quiet market, and the missing half is discovered when a buyer asks about a listing they saw elsewhere.

Availability in the UAE and the wider GCC

United Arab Emirates

Bayut's core market, alongside Property Finder. Dual listing is the norm and deduplication is therefore the central problem rather than an edge case.

Saudi Arabia and wider region

Portal presence and advertising regulation both vary. Confirm per market rather than assuming the UAE arrangement carries.

Third-party listing search

Not available, as with the other portal. The integration reads your own inventory.

Single-portal brokerages

Deduplication is unnecessary and the integration is simpler. Worth confirming, since building for a case you do not have adds machinery for nothing.

When not to use this integration

You list on one portal only. Deduplication is the reason this integration is more work, and without dual listing it is machinery for nothing.
Your feeds have no stable attributes to match on. Composite identity needs building, size and bedroom count at minimum.
Nobody will review ambiguous matches. Holding for review only works if somebody looks at the queue.
You want portal-wide search. Not available here either, and building around it means building on a terms violation.

What it runs on

Component	Version	Why
Cloudflare Workers	current	Scheduled fetch per feed, deduplication and matching.
Cloudflare D1	current	Deduplicated listings, source records and the review queue.
Cloudflare R2	current	Per-feed snapshots retained for diffing and discrepancy tracing.
Zod	4.4	Validation of feed records, which differ in shape between portals.

Questions that come up during scoping

Why can we not deduplicate on the listing reference?

Because each portal issues its own reference and they do not correspond. Matching on reference guarantees every dual-listed property is treated as two, which is exactly the failure buyers notice first.

What does the composite identity use?

The attributes that stay the same between feeds — building or community, unit number where present, bedroom count, size and price band — with the RERA permit as a strong secondary signal, since the same property carries the same permit on both portals.

What happens when the two feeds disagree on price?

The most recently updated record wins and the discrepancy is logged. Price changes are confirmed against the same source before alerting, so buyers are not told about reductions that are really a sync lag.

Should we wait for both feeds before alerting?

No. One feed usually leads the other by minutes or hours, and the whole point is speed to the buyer. Alert on first sight and record which feed it came from, so a later discrepancy is explicable.

What if two different flats get merged?

Worse than showing two records, because an incorrectly merged property becomes invisible to every buyer looking for it. Ambiguous matches are held for agent review rather than resolved by guessing.

How do we know if one feed has stalled?

Per-feed staleness alerts. Without them a stalled feed looks like a quiet market, and the missing inventory is discovered when a buyer asks about a listing they saw on the other portal.