Tracking Israel Post Shipments Automatically: What Actually Exists

The need is simple: a customer ordered, a parcel shipped, and you want the system to know when it was delivered - without someone pasting a tracking number into a website by hand. Anyone searching for "Israel Post API" quickly finds the answer is less direct than expected, and most businesses end up in the same place.

First: ask, do not infer

I am not publishing an endpoint here. Whether a documented public interface exists, and for which account type or agreement, is a question to put directly to Israel Post - in writing, before pricing.

Why I insist on that: this is precisely the case where a two-year-old article quoting an endpoint sends a developer chasing something that changed or was never available for their account. The same rule I apply to iCount and Hashavshevet.

Two specific questions worth asking:

1. Is there a programmatic tracking interface, and what is required to get access?
2. Is it available to an ordinary business customer, or only under a commercial agreement?

What most businesses actually do

The common route is a multi-carrier aggregator - a third-party service normalising tracking across hundreds of carriers into one format, Israel Post included.

And that is not a compromise. It is usually the right choice, for a business reason rather than a technical one:

The deciding point: most businesses do not ship only with Israel Post. There is a courier for the city, post for outlying areas, perhaps an international carrier. Build three separate integrations with three different status models and you have built three systems to maintain. An aggregator makes it one.

What to check before choosing a provider:

• Whether Israel Post is covered and at what level of detail.
• Whether webhooks exist or only polling. That matters more than it sounds - see below.
• What happens when a carrier returns no update. A provider presenting "no information" as a failure is noise; one distinguishing "not yet" from "failed" is useful.

The decision that matters more than the source: webhooks or polling

This is what most affects cost and experience.

Shipment tracking is a rare event. A parcel changes status perhaps three or four times over several days. Polling every open parcel hourly means hundreds of calls, most returning "no change".

If webhooks exist, use them. And as with any webhook: verify the notification genuinely came from the provider, respond immediately, and be idempotent - the same update can arrive twice and that must not send the customer two messages.

If only polling: poll open parcels only. A delivered parcel needs no further checking, and a parcel that has not moved in a fortnight probably will not - take it out of the cycle and flag it for a human.

Status mapping - the step everyone skips

Carriers return their own wording, in Hebrew and English, and it changes. Do not show the customer what the carrier said.

The reason is practical: add a second carrier and you have two vocabularies on one screen. And when a carrier changes its wording, your interface changes without you touching it.

What works: a small set of your own - shipped, in transit, awaiting collection, delivered, problem - and a translation layer from the carrier into it. The customer sees one consistent state.

And keep the raw status alongside. When something looks odd, that is the evidence of what the carrier actually said.

What breaks in practice

• "No information" is not a failure. A parcel handed in an hour ago is not in the system yet. Distinguish "not yet" from "error", or you will alert on nothing.
• A wrong tracking number. Typed by hand, or the shipment was cancelled. After a few attempts, drop it from the cycle and flag it rather than retrying forever.
• A delivery that never gets reported. It happens. A job flagging orders stuck beyond X days is worth more than trying to fix the tracking.
• Hebrew in the customer message. A Hebrew status with a tracking number on the same line is mixed text, and in an SMS or WhatsApp message there is no CSS to sort it out.

What it is worth to the client

Worth saying before building: automated tracking does not make shipments faster. What it gives:

• Fewer "where is my order" contacts. That is the real saving, and it is quantifiable - how many such contacts per month.
• Early detection of a stuck parcel, before the customer complains.
• Automatic order closure in the system on delivery.

And if the number is five contacts a month - say plainly that it does not justify a project. Updating open parcels by hand once a day costs less than an integration somebody has to maintain.

Checklist

1. Ask Israel Post in writing what exists and for whom - before pricing.
2. If shipping with more than one carrier, an aggregator is almost always better.
3. Check whether webhooks exist; if so, use them.
4. Poll only open parcels, and retire stuck ones from the cycle.
5. Map to your own status set and keep the raw value.
6. Idempotency - a duplicate update does not send two messages.
7. Quantify the monthly "where is my order" volume before building.