Checking an Israeli Company Automatically: Where the Data Comes From

The recurring request: a business customer signs up, and you want to verify automatically that the company exists and the details are right. In Israel, company registration data is published as part of the government open data - meaning not as a live lookup service but as a dataset. That distinction determines how the process should be built.

To be clear: this article covers the engineering aspect only. What exactly you are permitted to do with the data, and what is required for compliance or due diligence, are questions for a lawyer rather than a developer.

Where it comes from and what that means

The data is published on the government open data portal, which runs on CKAN. The practical implications are covered in the data.gov.il API guide; three points matter here:

• You fetch a dataset, you do not ask a question. There is no "does this company exist" endpoint - there is a file you retrieve and query on your side.
• There is a currency, and it has an age. A dataset updates at some cadence, and that does not mean "now". A company registered yesterday is not necessarily in it.
• The structure can change without notice. True of all open data, and it demands column validation on every run.

The design conclusion: download the dataset, store it on your side, and search locally. Do not attempt a live fetch on every signup request - that is slow, fragile, and puts public infrastructure availability in the critical path of your onboarding.

The key: registration number, not name

This is the point that determines whether the process works at all.

A company name is not an identifier. It is not unique, it changes, and it is written several ways: with and without the limited-company suffix, with different quote characters, in Hebrew and in English, with double spaces. Three spellings can be one company - or three different ones.

A registration number is an identifier. Stable, unique, and present on every official document.

So the most important consequence is for your signup form, not your code: if you want verification capability, ask for the registration number at intake. Adding it later to thousands of existing records is manual work with no shortcut.

That same number is also the best join key between a CRM and an ERP, for exactly the same reason.

What an automated check actually gives you - and what it does not

This is the distinction most worth conveying to a client before promising anything.

The first row on the right is the substance. "The company exists" and "this person may commit it" are entirely different questions, and the second is not answered by open data. A system displaying "verified" after a number check alone creates confidence that does not exist.

If the need is genuine compliance or due diligence - that is not a technical question, and it belongs with whoever owns the business process.

What breaks in practice

Hebrew text matching

Even with a valid number, comparing names produces false mismatches. In Israeli data it is always the same patterns: double spaces, invisible characters at the edges, several different quote characters, and a limited-company suffix that is sometimes part of the name and sometimes not.

Normalise before comparing - strip extra whitespace, unify quote characters, and compare without the suffix. And remember a partial match is not a failure; it is a reason to show the user and ask them to confirm.

The age of the data

Record when the dataset was last refreshed, and display it. "Checked against data from the 15th" is useful information; "verified" with no date is misleading.

A company that is not found

Most important: not finding it is not proof the company does not exist. It may be new, registered differently, or the number may have been mistyped.

Never reject a signup automatically on that basis. Flag it for human review and let the process continue. A business that rejects a real customer over a data gap has lost a customer and will not know it happened.

The pattern that works

1. Ask for the registration number on the form - the single highest-impact change.
2. Fetch the dataset on a schedule and store locally, with a refresh timestamp.
3. Validate structure on every run and alert if a column changed or the row count collapsed.
4. Normalise text on both sides before comparing.
5. Look up by number, and use the name only for visual confirmation.
6. A mismatch flags, it does not block.
7. Store what was checked and when - that is the evidence when someone asks.

When not to build this at all

A question worth asking before starting: how many business customers are onboarded per month?

If the answer is ten, a manual check takes minutes and gives a better result - because a person also sees what the data does not cover. Automation pays off on volume, or when onboarding delay costs money.

And if the need is merely "the number should look valid" - a format validation on the form delivers most of the value for a fraction of the work, with no external dependency at all.