edgeprop.my logo
edgeprop.my

find-agent-contact-details

Installation

Adds this website's skill for your agents

 

Summary

Extract a Malaysian real-estate agent's display name, full mobile phone (E.164), and email from any EdgeProp.my agent profile or listing page by parsing the inlined Next.js __NEXT_DATA__ payload — bypasses the UI's masked phone and email-form gateway.

FIG. 01
FIG. 02
FIG. 03
FIG. 04
FIG. 05
FIG. 06

Replay unavailable for this skill yet.

SKILL.md
218 lines

EdgeProp.my Find Agent Contact Details

Purpose

Given an EdgeProp.my agent profile URL (/agent/{id}/{slug}) or any listing URL (/listing/sale/{id}/... or /listing/rent/{id}/...), return the listing agent's full display name, full unmasked mobile phone number (E.164 normalized for Malaysia), and email address. Read-only — never submits the Send Enquiry form, never books or contacts the agent.

When to Use

  • Looking up the contact details of a specific listed real-estate agent on EdgeProp Malaysia.
  • Building a contact card for any Malaysian property listing (sale or rental) — pulls the agent off the listing without the user needing to know the agent's own URL.
  • Bulk enrichment of agents discovered via /agents directory pages or via Browserbase Search results pointing at edgeprop.my/agent/....
  • Anywhere you'd otherwise scrape the rendered UI and chase the "Show Number" click-to-reveal — the JSON payload embedded in the page exposes the full phone and email upfront, so the click is wasted work.

Workflow

EdgeProp.my is a Next.js application sitting behind Cloudflare's managed-challenge bot protection. The page UI masks the agent's phone as 01X XXX XXXX and only offers an enquiry-form gateway for email — but the <script id="__NEXT_DATA__"> payload that Next.js inlines on every server-rendered page contains the agent's raw, unmasked phone and email in plaintext. Fetch the page once with a real Chromium that can pass the Cloudflare challenge, parse __NEXT_DATA__, done. No clicks, no enquiry form, no waiting on XHR reveals.

Cloudflare blocks plain curl / wget / non-residential HTTP with a 403 + JS challenge — confirmed during iteration. You must use Browserbase remote + --verified (residential captcha-solver flag) + --proxies (residential proxies) and let the page sit for ~10–15s after first navigation for the CF challenge to clear. After that the page is unchanged from a normal browser session.

  1. Start a stealth Browserbase session with both --verified and --proxies:

    sid=$(browse cloud sessions create --keep-alive --proxies --verified \
  | node -e "let s='';process.stdin.on('data',c=>s+=c).on('end',()=>process.stdout.write(JSON.parse(s).id))")
export BROWSE_SESSION="$sid"

  2. Navigate to the target URL — either an agent profile (/agent/{id}/{slug}) or any listing (/listing/sale/..., /listing/rent/..., /rental/...). Wait ~12–15 seconds for Cloudflare's managed challenge to auto-clear. The title flips from "Just a moment..." to the real page title once cleared.

    browse open "https://www.edgeprop.my/agent/103203/eleen-ooi" --remote
browse wait timeout 15000 --remote
browse get title --remote   # confirm: not "Just a moment..."

  3. Extract the __NEXT_DATA__ JSON from the page — Next.js inlines it as a <script id="__NEXT_DATA__" type="application/json">…</script> element. Parse it as JSON.

    browse get html "//script[@id='__NEXT_DATA__']" --remote > nextdata.html
# The .html field of the returned JSON envelope is the literal stringified JSON payload.

  4. Read the agent object — field names differ between the two page types:

    Agent profile page (/agent/{id}/{slug}) — at props.pageProps.data.agent:

    JSON pathMeaning
    bizname_tDisplay name, e.g. "Eleen Ooi"
    contact_sRaw phone, no formatting, e.g. "0122829900"
    mail_sEmail, e.g. "eleenestates@outlook.com"
    org_name_sAgency slug, e.g. "cbdproperties" (lowercase, no spaces)
    agent_position_sPosition/title text, e.g. "Real Estate..."
    uid_iNumeric agent id matching the URL {id}

    Listing page (/listing/{sale|rent}/{id}/...) — at props.pageProps.JSONdata.result.agent:

    JSON pathMeaning
    agent_biznameDisplay name as shown on listing card, e.g. "DANIEL KHO" (often UPPERCASE on listings)
    agent_nameLegal name from BOVAEP registry, e.g. "KHO CHEE YONG" — frequently different from agent_bizname. Report agent_bizname as the public-facing answer unless caller specifically wants the legal name.
    agent_phRaw phone, e.g. "0162690803"
    emailEmail, e.g. "danielkho24@gmail.com"
    agency (a.k.a. agent_com)Full agency name, e.g. "IQI REALTY SDN. BHD."
    agent_idBOVAEP/PEA registration, e.g. "REN 16300" or "PEA 3651"
    uidNumeric agent id — use to construct the canonical /agent/{uid}/{slug} URL

  5. Normalize the phone to E.164. Malaysian mobile numbers start with 01 (e.g. 012…, 016…, 017…, 018…, 019…, 011…, 013…, 014…, 015…). Strip any non-digit characters, drop the leading 0, prepend +60. Examples: 0122829900 → +60122829900; 016-269 0803 → +60162690803. Keep the original raw string as phone_raw so the caller can verify.

  6. Output the JSON envelope from the Expected Output schema below. If the field genuinely isn't in __NEXT_DATA__ (rare — observed only when the agent record is suspended/archived), fall back to the Browser fallback below.

Browser fallback (rare — only when __NEXT_DATA__ is missing or stripped)

Older PRO-tier accounts or archived listings occasionally render with __NEXT_DATA__ absent or with the contact fields blanked. In that case revert to the on-page click-to-reveal flow — it's reliable, just slower:

  1. On the agent profile page, the phone is shown as a button labeled 01X XXX XXXX (last 4 digits masked) next to a green WHATSAPP button. Click the masked-phone button to reveal the full number: 
    browse click "//button[.//span[contains(text(),'XXXX')]]" --remote
browse wait timeout 2000 --remote
browse get text "//*[contains(text(),'01') and not(contains(text(),'XXXX'))]" --remote
    The masked-phone button text updates in place from 012 282 XXXX → 012 282 9900. The WHATSAPP button next to it triggers a window.open(wa.me/<phone>) that gets popup-blocked in headless sessions — don't rely on it for extraction.
  2. Email cannot be revealed via UI — the SEND ENQUIRY button opens a contact form that asks for the visitor's email + message; the agent's email never appears in the rendered UI. If mail_s / email is absent from __NEXT_DATA__ and the click-reveal flow is your only path, set email: null and email_form_only: true.
  3. On listing pages, the on-card phone affordances (WHATSAPP, MOBILE CALL) under "OTHER WAYS TO ENQUIRE" do not flip the UI to show a number — they each fire a window.open that's popup-blocked. From a listing page, the reliable click-reveal path is to navigate to the agent's profile (the contact card has an /agent/{uid}/{slug} anchor on the agent's name) and reveal there. Many listing descriptions also contain the agent's phone written into the body text by the agent themselves — that's a noisy source, prefer __NEXT_DATA__.

Site-Specific Gotchas

  • Cloudflare managed challenge is mandatory. browse cloud fetch (no browser) and any plain HTTP client return a 403 with cf-mitigated: challenge and the JS-only "Just a moment..." interstitial. Only a real Chromium with --verified --proxies clears it. First navigation needs 10–15s of post-load wait — calling browse get title immediately will return "Just a moment...".
  • __NEXT_DATA__ is the goldmine — and the UI lies about what's hidden. The HTML rendered into the visible DOM masks phones as 01X XXX XXXX and offers no email at all. The exact same page's <script id="__NEXT_DATA__"> block contains both fields in plaintext (contact_s + mail_s on agent pages, agent_ph + email on listing pages). Do not waste turns clicking reveal buttons unless __NEXT_DATA__ is unexpectedly absent.
  • Field names differ between agent profile and listing pages. Agent profile uses Solr-style suffixed keys (contact_s, mail_s, bizname_t, org_name_s); listing pages use a agent sub-object with descriptive keys (agent_ph, email, agent_bizname, agency). Both are documented in step 4 above. Don't assume one schema — check the URL path first.
  • Two name fields on listings: agent_name ≠ agent_bizname. agent_name is the legal name registered with BOVAEP (Malaysian Board of Valuers, Appraisers, Estate Agents and Property Managers), e.g. "KHO CHEE YONG". agent_bizname is the public-facing display name, e.g. "DANIEL KHO". The site UI exclusively shows agent_bizname — report that as name unless the caller specifically asks for the registered legal name.
  • Listing-page agent_bizname is often UPPERCASE ("DANIEL KHO") while agent-profile bizname_t is Title Case ("Daniel Kho"). Normalize to Title Case in the output if you care about presentation consistency.
  • License-number format is non-uniform. REN 16300 = Registered Estate Negotiator. PEA 3651 = Probationary Estate Agent. E (…) / VE (…) exist for fully-registered Estate Agents and Valuers. Surface the raw string; don't try to canonicalize.
  • Phone format quirks. contact_s / agent_ph are returned without dashes ("0162690803"). Some agent records have the phone also embedded in listing-description body text in stylized Unicode (e.g. 𝟎𝟏𝟔𝟐𝟔𝟗𝟎𝟖𝟎𝟑) — that's noisy, ignore it. Trust agent_ph / contact_s. Malaysian mobile prefixes observed: 010-019. To E.164, strip leading 0, prepend +60.
  • The "SEND ENQUIRY" button opens a contact form, not a mailto. The form fields are the visitor's full name, email and mobile — the agent's email is never exposed via this UI affordance. Do not submit this form during scraping (it would send a real lead to the agent).
  • WHATSAPP buttons rely on window.open(...) and get popup-blocked in headless Browserbase sessions. They never produce an inspectable wa.me/<phone> href in the DOM. Don't try to harvest the phone via WhatsApp click.
  • Don't trust data.org_name_s as the human-readable agency. It's a slug ("iqirealty", "cbdproperties"). The listing-page agent.agency / agent.agent_com field is the proper display name ("IQI REALTY SDN. BHD.", "CBD PROPERTIES SDN. BHD.").
  • Agent profile URLs are case-insensitive in the slug. /agent/101419/daniel-kho, /agent/101419/DANIEL%20KHO, and /agent/101419 all resolve to the same page. The numeric {uid} is the only stable identifier.
  • robots.txt is generous — /agent/... and /listing/... are not in the Disallow list (only /admin/, /search/, /user/... are). Crawl-delay: 10 is advisory; keep request rate sane.
  • Cookies / sign-in are not required. All the data above is present in the unauthenticated page payload. Don't burn turns trying to log in.
  • Email is sometimes missing from __NEXT_DATA__ when the agent has set their profile to hide email (free-tier accounts more often than PRO-tier). When mail_s / agent.email is "" or absent, report email: null with email_form_only: true — don't fabricate one from the listing description.
  • Iteration cost note: per-iteration cost is dominated by the Browserbase session minutes (the --verified solver adds a few seconds to first-load). Budget ~15–30s per agent if reusing a session, or ~30–45s if creating a fresh session each time. Reuse sessions when bulk-extracting.

Expected Output

{
  "success": true,
  "name": "Eleen Ooi",
  "name_legal": null,
  "phone": "+60122829900",
  "phone_raw": "0122829900",
  "email": "eleenestates@outlook.com",
  "agency": "CBD PROPERTIES SDN. BHD.",
  "license": "PEA 3651",
  "agent_id": 103203,
  "agent_profile_url": "https://www.edgeprop.my/agent/103203/eleen-ooi",
  "source_url": "https://www.edgeprop.my/agent/103203/eleen-ooi",
  "extraction_method": "next_data",
  "email_form_only": false,
  "error_reasoning": null
}

Listing-page example (agent has a different legal vs. business name):

{
  "success": true,
  "name": "Daniel Kho",
  "name_legal": "KHO CHEE YONG",
  "phone": "+60162690803",
  "phone_raw": "0162690803",
  "email": "danielkho24@gmail.com",
  "agency": "IQI REALTY SDN. BHD.",
  "license": "REN 16300",
  "agent_id": 101419,
  "agent_profile_url": "https://www.edgeprop.my/agent/101419/daniel-kho",
  "source_url": "https://www.edgeprop.my/listing/sale/3726402/pandan-ria-apartment-for-sale-by-daniel-kho",
  "extraction_method": "next_data",
  "email_form_only": false,
  "error_reasoning": null
}

Email-hidden outcome (free-tier agent or hidden-email setting):

{
  "success": true,
  "name": "<agent display name>",
  "name_legal": null,
  "phone": "+60XXXXXXXXX",
  "phone_raw": "0XXXXXXXXX",
  "email": null,
  "agency": "<agency name>",
  "license": "<REN ####|PEA ####|E (#####)>",
  "agent_id": 999999,
  "agent_profile_url": "https://www.edgeprop.my/agent/999999/<slug>",
  "source_url": "<input url>",
  "extraction_method": "next_data",
  "email_form_only": true,
  "error_reasoning": "Email not present in __NEXT_DATA__ (mail_s empty). Agent's contact form is the only public email path."
}

Cloudflare-block / unreachable outcome:

{
  "success": false,
  "name": null,
  "name_legal": null,
  "phone": null,
  "phone_raw": null,
  "email": null,
  "agency": null,
  "license": null,
  "agent_id": null,
  "agent_profile_url": null,
  "source_url": "<input url>",
  "extraction_method": null,
  "email_form_only": false,
  "error_reasoning": "Cloudflare managed challenge did not clear within 30s. Retry with a fresh session using --verified --proxies, or wait and retry from a different residential IP."
}