Real Estate Portal CRM Integration: API vs Webhooks vs CSV
Published 4 November 2026 · By the SurePlot team
When an Indian broker or builder asks for a “99acres CRM integration” or “MagicBricks CRM integration”, the important question is not whether two logos appear on a vendor’s website. It is what actually happens after a buyer submits an enquiry: which system sends the record, which fields arrive, how quickly it is delivered, and what happens when the connection fails.
There is no single integration method used by every property portal or every CRM. Depending on the provider, account and plan, lead delivery may use an API, a webhook, email notifications, a partner connector or a CSV export. This guide explains the differences and gives you a way to test the complete workflow before you depend on it.
First, define what you need to connect
“Portal integration” can describe several different jobs. Ask for the exact one you need before comparing vendors:
- Inbound lead capture: new buyer enquiries from a portal are created in your CRM, with the source and listing context retained
- Listing syndication: property details are sent from your system to a portal so that listings can be published or updated
- Inventory synchronisation: availability, price or unit status is exchanged between systems
- Activity or status synchronisation: call outcomes, lead status or other updates move between systems
Four common ways portal leads reach a CRM
The connection method determines what can be automated and what you need to monitor. A provider may also use a third-party connector behind the scenes, so ask the vendor to name the underlying method rather than accepting “direct integration” as the full answer.
A webhook is an event-delivery pattern, not a guarantee that a portal offers one. In a generic webhook model, the source sends an HTTP request when an event occurs, while API polling asks for data at intervals. GitHub’s documentation explains this distinction clearly; use it as a technical reference, not as evidence of any property portal’s own capabilities.
For a real-estate example, LeadSquared’s public help articles describe Sulekha and MagicBricks connectors that use a CRM-generated webhook URL configured with the portal account. Those are LeadSquared’s documented setups: they do not prove that every portal account, CRM plan or provider uses the same process.
| Method | How it works | Useful when | What to verify |
|---|---|---|---|
| API pull | The CRM requests lead records from a provider endpoint, either on demand or on a schedule. | You need structured records and controlled, repeatable synchronisation. | Access approval, polling interval, rate limits, pagination, token expiry, updates and historical backfill. |
| Webhook push | The provider sends an event and its data to a URL configured for your CRM. | The provider supports event delivery and you want new enquiries to arrive without waiting for the next polling cycle. | Who configures the URL, HTTPS and request authentication, retries, duplicate-event handling, delivery logs and failure alerts. |
| Email parsing | A connector reads portal notification emails and extracts lead details. | The portal already sends useful enquiry notifications and no direct connection is available. | Mailbox access, sender validation, template changes, forwarded messages, attachments, missing listing IDs and duplicate emails. |
| CSV import or export | A user downloads a file and imports it into the CRM, or exports CRM records for another system. | You are migrating old leads, reconciling records or using a manual fallback. | Column mapping, date and phone formats, update-versus-create behaviour, duplicate handling and who owns the recurring upload. |
Lead capture is not the same as listing or inventory sync
A connector that receives buyer enquiries may not publish your listings, update unit availability or synchronise prices. These are separate data flows, often with different permissions and risks. A broker who only needs inbound enquiries should not pay for a broad “two-way integration” without seeing which records actually move in both directions.
For a builder, ask whether the connector only receives project enquiries or also reads unit-level inventory. If inventory is involved, define which system is authoritative for availability and price. Decide what happens when two systems show different values, and do not let an old portal update overwrite a newer confirmed booking.
- Write down the direction of each data flow: portal to CRM, CRM to portal, or both
- Name the system that owns each field, such as listing status, unit availability and asking price
- Agree how edits, cancellations and failed updates are reconciled
- Test a changed record as well as a brand-new enquiry
Map the fields that your sales team actually needs
Keep the portal’s external ID where one is provided. If it is absent, use a cautious duplicate-review rule based on available fields such as a normalised phone number, listing or project and time window. Do not automatically merge two records just because the names look similar: family members may share a phone, and one buyer may enquire about several different properties.
| Field | Why it matters |
|---|---|
| Portal and source account | Separates enquiries by portal, advertiser account, branch or campaign. |
| External lead or enquiry ID | Provides a stable reference for checking delivery and detecting repeat events. |
| Listing, property or project ID | Helps the agent identify the property that triggered the enquiry. |
| Received time and import time | Shows when the buyer enquired and when the CRM received the record. |
| Name and contact details | Lets the team contact the buyer; normalise phone numbers consistently without treating a shared number as proof that two people are the same. |
| Original enquiry text and enquiry type | Preserves what the buyer asked, including call, chat, form or other provider-specific context. |
| Locality, configuration and budget | Keeps the requirement available for matching; do not silently invent values when the portal did not send them. |
| Lead owner, status and next action | Makes responsibility and the next follow-up visible after capture. |
The integration test: do this before you call it live
Ask the vendor and your portal account contact to run a controlled test using an enquiry you are authorised to create. Check the record in the portal and the CRM side by side. A screenshot of a settings page is not a successful end-to-end test.
- Confirm the exact portal account, package and enquiry types included in the connection.
- Record the connection method and who is responsible for configuring it.
- Submit a test enquiry against a known listing or project.
- Check the source, external lead ID, listing or project reference and original enquiry text.
- Compare the portal’s event time with the CRM’s received time; agree an acceptable delivery window rather than assuming “real time”.
- Check that the lead is assigned to the correct agent or an explicit unassigned queue.
- Submit a repeat event or use the provider’s test facility to verify duplicate handling.
- Test an update to an existing enquiry if the provider supports updates.
- Review what happens when the CRM endpoint, mailbox or API credentials are unavailable.
- Find the delivery logs, error alerts and retry or replay process.
- Check who can view, export and delete lead data, and how access is removed when an employee leaves.
- Document the expected behaviour and the person to contact when a lead is missing.
Common integration failures and how to catch them
For a small team, a daily reconciliation can be as simple as comparing the portal’s enquiry count with the CRM’s received count for the same period, then investigating the difference. For a larger team, ask for delivery logs, failure alerts and a documented replay process. A connector should make missing records visible, not hide them.
| Symptom | Likely cause to investigate | Practical check |
|---|---|---|
| Lead appears with no property context | Listing ID was not sent, mapped or matched. | Compare the portal enquiry with the CRM record and test a known listing. |
| The same enquiry appears twice | A provider retry, email forward or repeat import created another record. | Check external IDs and event logs before changing the deduplication rule. |
| Some enquiry types never arrive | The account connection covers only selected lead types or delivery routes. | Test each enquiry type listed in the agreement, not just one sample form. |
| Leads stop arriving unexpectedly | Credentials, permissions, mailbox access or provider settings changed. | Check connection health and the last successful delivery timestamp. |
| Leads arrive but no one follows up | The integration created records without an owner or assignment rule. | Test routing for each project, branch and agent availability scenario. |
Protect enquiry data and keep WhatsApp follow-up expected
Portal enquiries contain personal data. Give buyers a clear explanation of why you collect and use their details, collect only what the sales process needs, restrict exports and staff access, and define when records should be reviewed or deleted. India’s Digital Personal Data Protection Act, 2023 and the notified Rules are the primary official references; how particular obligations apply depends on the processing and applicable commencement provisions, so get advice for your business rather than treating a CRM setting as legal compliance.
If your workflow sends promotional WhatsApp messages, make sure the recipient has agreed to receive the relevant communication, identify your business and message purpose clearly, and honour requests to stop. Meta’s current business-messaging guidance emphasises expected, relevant messages and opt-in before marketing messages. A portal enquiry should not become permission for unlimited unrelated broadcasts.
Run a small pilot before connecting every portal
Start with one portal account, one project or listing group and a small set of agents. The exact timeline depends on provider access, but a controlled pilot is more useful than switching every source on at once.
Only expand the connection when the pilot is repeatable and the team knows how to detect and resolve a failed delivery. If a vendor cannot demonstrate a test lead from your own account, treat the integration as unverified.
- Before setup: write down the required lead types, fields, owners and expected delivery window.
- During setup: connect the account and capture a controlled test enquiry for each required enquiry type.
- During the pilot: reconcile portal and CRM counts daily, review duplicates and missing fields, and ask agents whether the listing context is usable.
- Before rollout: document support ownership, error handling, access controls and the fallback process.
- After rollout: review missing-lead rate, duplicate rate, assignment accuracy and time-to-first-action by source.
How to evaluate SurePlot’s portal workflows
SurePlot has dedicated information pages for supported enquiry workflows from several property and business portals. The pages explain that connection availability and delivery depend on the provider and account configuration. Before enabling a source, confirm the exact enquiry types, method, required portal permissions, field mapping and plan availability for your account.
The takeaway
A useful property-portal integration is more than a lead appearing in a CRM. It preserves the original enquiry and listing context, assigns a clear owner, handles retries and duplicates safely, and gives your team a way to spot missing records. Compare the method, test it in your own portal account and document the failure path before you rely on it for daily sales.
Put this into practice with Sureplot
SurePlot helps Indian real estate teams organise supported enquiries, property information and follow-up activity. Start with the Free plan; paid plans begin at ₹699/month.
Explore SurePlot