Zoho CRM integration with Idealista and Fotocasa

In a real estate agency, a lead that arrives from Idealista or Fotocasa at nine in the morning and gets answered at six in the evening is already dead. That prospect enquired on three other listings too, and whoever called first has taken them. The problem is not a shortage of leads: it is that they arrive from several places at once, pile up in a shared inbox, and nobody knows which one is new, which is a duplicate, and whose turn it is.

Integrating Zoho CRM with Idealista and Fotocasa fixes exactly that: every enquiry lands in the CRM on its own, with no duplicates, linked to the right listing, tagged with the source portal, and assigned to an agent in seconds. It sounds straightforward, but each portal exposes its leads differently, and that is where most integrations break. Let’s get into the detail.

How the lead actually arrives from Idealista and Fotocasa

The first thing to understand is that “connecting the portal” is not a single thing, because each portal plays by different rules.

Idealista offers a leads API through its partner and professional-plan programme. When you have access, contacts arrive structured: name, phone, email, listing reference and message, in a JSON you can read and push into Zoho without guessing anything. That is the reliable route. The catch is that not everyone gets it: access depends on your account type and on Idealista enabling the feed for you.

Fotocasa (part of Adevinta) works mostly through email notifications and its own lead manager; direct programmatic access is more limited depending on the plan. In practice, many agencies receive the Fotocasa lead as an email with a fixed format.

That leaves two technical paths, and you almost always end up combining both:

• Via API, when the portal exposes one. This is the robust option: structured data, less fragile against visual changes to the email.
• Via email parsing, when there is no API. You set up a dedicated mailbox (for example [email protected]), route the portal notifications there, and a function reads each email, extracts the fields by pattern, and creates the record in Zoho.

Email parsing works well, but it has an Achilles heel worth keeping in mind from day one: if the portal changes the email format, your extraction stops finding the fields and leads come in empty or stop coming in at all. That is why the parser must never fail silently (more on that below).

Real scenarios we run into

The same lead comes in through Idealista, Fotocasa and the website

This is the most common one and the one that hurts most. A prospect sees the same flat advertised on both portals, fills in the form on each, and also lands on your website. Within minutes you have three enquiries from the same person. With no de-duplication, three contacts are created, three different agents call them, and the client perceives a disorganised agency.

The fix is not a button: it is a matching strategy at the point of entry. Before creating anything, we normalise the phone (strip spaces, the +34 prefix, leading zeros) and the email (lowercase, no spaces), and we do a “find or create”: if a contact already exists with that phone or email, we do not create another; we add the new enquiry as one more activity or Deal, linked to the listing they asked about this time. That way one person interested in two flats generates a single contact and two opportunities, not four loose records.

Linking the lead to the listing and knowing which portal converts

A lead with no listing reference forces the agent to ask “which flat were you calling about?”, which undermines credibility. Both Idealista and Fotocasa send a listing reference; the work is mapping that reference to your properties module in Zoho (a custom module or whichever real estate CRM you use) so the record shows the exact flat.

Just as important is storing the source in its own field (Lead Source = Idealista / Fotocasa / Web), not buried in the message text. That field is what later lets you report how many leads and how many sales each portal brings, and decide with data whether Fotocasa pays off or whether Idealista is eating your budget without closing. Without that clean tagging from the source, portal-level profitability reporting is impossible to reconstruct after the fact.

Assignment and speed to lead

In real estate lead capture, speed to lead is almost everything: the first to call has a huge advantage. So as soon as the lead comes in and is de-duplicated, it is assigned automatically. We set up round-robin distribution across available agents (or by area, or by property type), a task is created with an immediate due time, and a notification fires. If nobody logs the first contact within X minutes, it escalates: it jumps to a manager or gets reassigned. That first-contact SLA, measured inside Zoho, is what turns “we have plenty of leads” into “we close leads”.

How we approach it

After building these connections for agencies, the order matters as much as the technique.

We decide the model first, not the API. We define what a contact is, what an opportunity (Deal) is, and how it relates to the listing, before touching any portal. A modelling mistake here is paid on every single lead for months.

We fix the de-duplication keys and normalisation. Normalised phone and email as the primary key; “find or create” at every entry point (both portals and the website share the same logic). De-duplication is not a clean-up job you run on Fridays: it is a rule applied the instant the data comes in.

We choose API where we can and parsing where we must. For Idealista, the API if your account enables it. For Fotocasa, a well-armoured email flow. Every source writes into the same Zoho fields, so the agent works the same way regardless of where the lead came from.

We armour the parser against format changes. The mailbox is processed with tolerant rules, and if an email matches no known pattern, it is not discarded: it is stored raw and an alert fires so someone reviews it by hand and adjusts the parser. We never lose a lead to a portal changing its template.

Mistakes worth avoiding

• Letting duplicate contacts be created. Without normalising phone and email before creating, the same prospect comes in two and three times, and two agents call them. It is the failure that destroys the most trust.
• Losing the lead source. If you don’t store the portal in its own clean field, you will never know which portal is profitable and you’ll be paying for ads blind.
• Relying on email parsing alone with no plan B. The day Idealista or Fotocasa change the email format, you stop receiving leads and won’t notice until a client complains. You need an alert when an email fails to parse.
• Ignoring Zoho’s API limits. A massive initial import of historical leads with no rate-limit control cuts the sync exactly when you need it most.
• Not measuring first-contact time. With no SLA and no escalation, leads go cold in a shared inbox and the money spent on portals is wasted.
• Putting the listing reference in the message text. If it doesn’t go into a structured field tied to your properties module, the agent loses time and per-property reporting simply doesn’t exist.

Native or middleware: when each one fits

Not every project needs the same thing, and being honest here saves money. If you work with a single portal that exposes an API, low volume, and simple assignment rules, a flow with Zoho Flow or Deluge functions can be enough and is the cheapest to maintain. As soon as both portals come in at once, with email parsing, careful de-duplication, round-robin with escalation and source-level reporting, the logic grows and a bespoke integration service pays off — one that controls errors, retries, and the changing-format case. The question is not “what is more modern?” but “how much does it cost me when a lead is lost silently?”.

If you want the full picture of how Zoho fits with the rest of your business — ERP, phone system, invoicing — we cover it in our Zoho CRM integration guide.

Closing

At LMNHUB we build Idealista and Fotocasa lead intake as an engineering project over your data: model first, de-duplication by design, tagged source, assignment with an SLA, and a parser that raises an alert before anything is lost. We don’t sell a magic connector; we leave a flow your team understands and that depends on no one.

If your agency loses leads between portals or answers them late, tell us about your case and we’ll get back to you with a concrete approach and a senior team — not a generic quote.