Israeli Real Estate Data: The Official Source Most People Skip

When someone asks to "collect real estate data", they almost always mean one of two questions: what is being asked or what was actually paid. The second - usually the real question - has an official, open and free source, and most people never reach it.

The distinction that decides everything

If the question is "what is a property in this area worth", an asking price is the wrong source. It tells you what an owner asked, not what a buyer paid, and the gap between them is precisely what is interesting.

So before building collection from any website - with all the terms-of-use questions that raises - check whether the official source already answers it.

The official source

The Tax Authority publishes a public real estate transaction database, covering sales of rights in property - including property type, block and parcel, sale date and value.

Alongside it there are two further access points worth knowing:

• The government real estate portal - an interface for searching transactions.
• The government geographic portal - transactions displayed as a map layer, alongside search by address or block and parcel.

And for programmatic work: the open data portal aggregates government datasets including the Tax Authority's, accessible through an API rather than only manual download.

What that changes practically: there is no terms-of-use question here as there is with collecting from a commercial site. The data was published for public use - exactly like retail shelf prices. That turns a project with a legal gate into an ordinary engineering project.

One caveat: each dataset carries its own licence, worth reading if you are building a commercial product on top. Access is permitted; commercial use is a separate conversation.

The join key: block and parcel

This is the most important technical point.

Israeli addresses are inconsistent across sources. The same property appears with and without the street prefix, with an apartment number appended, with the city spelled differently. Joining sources on address produces wrong matches.

Block and parcel is a stable cadastral identifier - and that is what allows reliable cross-referencing between sources. If your system records properties, it is worth storing.

What still requires work: block and parcel identify land, not an apartment. In a residential building dozens of flats share one parcel, so apartment-level matching also needs a sub-parcel or further detail. That is real work worth budgeting.

The three traps in transaction data

1. Reporting lag

A transaction reaches the public record after it completes and is registered - not on the day of signature. Which means the last two or three months are always incomplete.

And this is a classic analytical error: you look at a chart, see a sharp drop in the most recent month, and conclude the market stopped. It did not - the data simply has not arrived.

What to do: mark the recent period as incomplete in every display, or exclude it from trend analysis. And make sure whoever reads the report knows.

2. Not every transaction is what it appears

The database also includes transfers without consideration, transactions between relatives, and sales of partial rights. An average including those does not reflect a market price.

Before computing an average, understand which transaction types are included and filter what is irrelevant to the question.

3. Properties are not comparable

Two flats on the same parcel can be entirely different - floor, area, condition, balcony. An area average without normalising for size is a figure hard to draw conclusions from.

A reasonable minimum: price per square metre rather than absolute price.

What still needs normalising

As with all government data - see the guide:

• Structure changing without notice. Validate columns every run and stop if something moved.
• Amounts as text - with commas or currency symbols.
• Dirty Hebrew - double spaces and invisible characters in locality names.
• Dates in mixed formats.

And keep a raw copy. When a number looks odd in a month, that is the evidence of what was actually published.

When you do still need listing data

The official source is not always enough. It tells you what sold - not what is on offer now.

That last row matters: rentals have no official equivalent to the transaction register, so there listings are the practical source - with all the gates that raises.

When not to build

If the question is one-off - "how many flats sold in this area this year" - the public interfaces answer it in a browser, with nothing built.

Building pays off when continuous tracking is needed, when cross-referencing with your own data, or for analysis the interface does not allow. Otherwise it is infrastructure for a question asked once.

Checklist

1. Decide: asking price or transaction price. That determines the source.
2. Check the official source before building website collection.
3. Read the dataset licence if the product is commercial.
4. Store block and parcel as the key, not the address.
5. Mark the recent period as incomplete.
6. Filter transaction types that are not market prices.
7. Normalise to price per square metre, not absolute.