Integration
Property Finder, as a feed rather than a competitor
A Property Finder integration reads your own listings from the portal into a Telegram bot so registered buyers can be matched and alerted. Access is through your listing feed or your CRM rather than a public API, and the portal remains authoritative for what is published.
Property Finder integration: auth, limits and availability
- Auth model
- API key
- Read API
- No general third-party listing-search API is published
- GCC availability
- UAE core market; no equivalent portal coverage assumed elsewhere in the GCC
- Data flow
- 5 hops, worker-mediated
As of 2025-10-01, Telegram Bot API 13.4
Why this integration exists
A Dubai brokerage listing on Property Finder already maintains its inventory there, usually through a listing management system that pushes to several portals. Asking agents to re-enter inventory into a bot is the fastest way to guarantee the bot's data is wrong within a week, because the portal is where the commercial pressure to be accurate actually lives.
So the correct shape is that the bot reads rather than owns. Whatever system already publishes to Property Finder becomes the source, the bot ingests from it, and matching runs against buyers who registered criteria in Telegram. The bot's contribution is the buyer side — remembering what someone is looking for and telling them within seconds when something fits — not another place to type a listing.
The constraint worth stating plainly is that Property Finder does not offer a general public API for reading other people's listings, and scraping the portal is both against its terms and a poor foundation for a commercial product. What is available is access to your own inventory, usually through the feed your listing system already produces. That is enough for buyer matching and it is not enough to build a competing search product, which is the correct outcome.
How the data actually moves
In practice the integration authenticates to whatever system holds your inventory — a listing manager, a brokerage CRM, or a feed endpoint — rather than to the portal directly. Credentials are Worker secrets. Where only a scheduled feed file is available, it is fetched on a cron and diffed rather than polled aggressively.
Auth model: API key
Their limits, and what they mean for you
Property Finder does not publish a general read API for third-party listing search.
The integration reads your own inventory from your own systems. Anyone proposing to search the whole portal programmatically is describing a terms violation.
Dubai advertising regulations require a RERA permit number on property advertisements.
The permit is a required field on any listing the bot alerts on, and a listing without one is not sent. Enforcing it in the data model is what stops a busy agent creating a compliance problem.
Feed files represent a snapshot rather than a change stream.
Diffing against the previous snapshot is what produces new, changed and removed. Treating each fetch as a set of new listings alerts every buyer about everything, once per fetch.
Listing status changes are frequently the most delayed field in any feed.
A property under offer can remain marked available for hours. Alerts carry the freshness of the data rather than implying it is live, because the alternative is agents fielding calls about sold property.
How it fails, and what happens when it does
Every buyer is alerted about the entire inventory.
A diff was not performed, or the previous snapshot was lost. Snapshots are versioned and a diff producing an implausible number of changes is held for review rather than sent.
A buyer is alerted about a property that went under offer yesterday.
Status lag in the feed. Alerts state when the data was refreshed, and status is re-checked before an alert on a high-value listing rather than trusted from the last sync.
A listing without a permit number reaches an alert.
Blocked by the data model rather than by a checklist. The field is required and a listing lacking it is held rather than sent.
The feed endpoint changes or stops without notice.
A staleness alert fires when the feed has not updated within its normal interval. Silence in a feed is indistinguishable from a market with no new listings, which is why it must be monitored explicitly.
Availability in the UAE and the wider GCC
United Arab Emirates
Property Finder's core market and the case this integration is written for. RERA permit handling is specific to Dubai and is enforced in the data model.
Saudi Arabia, Qatar and Bahrain
Portal presence varies by market and so does the advertising regulation. Each market is confirmed separately rather than assumed from the UAE arrangement.
Third-party listing search
Not available and not something to build around. The integration reads your own inventory, which is what buyer matching actually needs.
Brokerages without a listing system
Agents enter listings in the bot directly instead. Workable, and it makes the bot a second source of truth, which is worth accepting deliberately.
When not to use this integration
- You want to search the whole portal programmatically. Not available, against the terms, and a poor foundation for a commercial product.
- Your inventory turns over slowly. Matching fires rarely and buyers forget the bot exists between alerts.
- Agents will not keep listing status current. Alerting buyers about sold property damages more trust than the alerts build.
- You have no listing system and no intention of getting one. The bot becomes a second source of truth, which is a decision rather than a default.
What it runs on
| Component | Version | Why |
|---|---|---|
| Cloudflare Workers | current | Scheduled feed fetch, diffing and match execution. |
| Cloudflare D1 | current | Listings, snapshots, buyer criteria and alert suppression. |
| Cloudflare R2 | current | Feed snapshots retained for diffing and for dispute resolution. |
| Zod | 4.4 | Validation of feed records, which vary in completeness by source. |
Questions that come up during scoping
Can the bot search all Property Finder listings?
No. There is no general public read API for third-party listings, and scraping the portal is against its terms and a poor foundation for anything commercial. The integration reads your own inventory, which is what buyer matching needs.
Why does the permit number matter so much?
Dubai advertising regulations require it on property advertisements, and an alert is an advertisement. The field is required in the data model so a listing without one is held rather than sent, which stops a rushed agent creating a compliance problem at speed.
Why do we need to diff the feed?
Because a feed file is a snapshot, not a change stream. Treating each fetch as a set of new listings alerts every registered buyer about the entire inventory, once per fetch, which is the fastest way to get the bot muted.
How current is listing status?
Status is usually the most delayed field in any feed, so a property under offer can still read as available for hours. Alerts state when the data was refreshed, and status is re-checked before alerting on a high-value listing.
What if our feed stops updating?
A staleness alert fires when it has not changed within its normal interval. Silence in a feed looks exactly like a quiet market, so it has to be monitored explicitly rather than inferred from the absence of alerts.
Does this replace our portal listings?
No, and it should not try. Portals are where buyers discover you. The bot is where buyers you have already met hear about new inventory first, which is a complementary job rather than a competing one.
Related reading
Most Dubai brokerages list on both portals, so see also the Bayut integration.
The bot this feed drives is the property listing build.
Filtering buyer enquiries before an agent calls is covered by the qualification build.
Where buyer records must live in a brokerage CRM, see the Zoho CRM integration.
To see feed ingestion priced alongside the rest of a brokerage build, see what a brokerage bot costs.