Israel Post vs Private Couriers: Comparing Integration Paths for an Online Store

Comparing Israel Post with a private courier for an online store is not a price comparison, it is an interface comparison: how much of the process can run from your own system, what information comes back, and what stays manual. Neither side publishes a public technical specification, and that single fact changes the order of the steps.

The two integration paths, stated plainly

Israel Post is an infrastructure provider with national reach, a large delivery-centre network, and dedicated e-commerce services for business customers. Its Click2post service is described on the site as distributing e-commerce parcels to roughly 1,000 delivery centres selected by the customer. The technical side is arranged with the business customer rather than published as open documentation.

A private courier - HFD, Cheetah, Tapuz and others - sells a service rather than infrastructure. It is built around e-commerce: platform integrations, its own pickup network, lockers, and sometimes warehousing and picking as well. Here too, the specification reaches the customer after an account is opened.

That is why a documentation-led technical comparison is not possible in Israel. You compare on published capabilities and on what each company will commit to in writing.

Criteria that genuinely differ

The table is meant to be filled in, not only read. Each row is a question worth sending to both sides in writing before deciding.

How is the technical interface actually obtained?

The same sequence in both cases, and it is the part that surprises developers most:

1. A commercial conversation and a business account.
2. Agreeing which service types will be active on that account - which is what determines what can be dispatched at all.
3. Receiving the connection details or the specification from the company.
4. Development, then testing against one real shipment.

The planning consequence is that an Israeli courier integration cannot be estimated before step 3. What you can build before it is everything that does not depend on the carrier: the dispatch gate, the internal status model, the shipments table and the event log. The same discipline is set out in tracking Israel Post shipments automatically, where the rule is to ask in writing rather than infer from an old article.

Tracking granularity and proof of delivery

Two terms that get conflated and should not be.

Tracking granularity is how many events you receive over the parcel's life, and how many of them mean anything to a customer. A parcel with two events - "accepted" and "delivered" - is effectively an untracked parcel from a support desk's point of view, because there is no answer for the whole middle of the journey.

Proof of delivery is what is recorded at the moment of handover. HFD publishes that its proof of delivery includes the time, the recipient's name and a signature. That is the data that ends a dispute with a customer.

Questions worth asking both sides:

• How many status events are actually produced on the service we are buying.
• Whether statuses are pushed to us or we are expected to poll.
• What is recorded at the moment of delivery, and how long it is retained.
• What comes back when delivery fails - a structured reason, or free text.

Returns: the criterion compared last and paid for first

For a store selling fashion or consumer goods, the return rate is often the most significant operational parameter, and it is usually examined at the end of the evaluation.

Three questions that decide it:

• Whether the return is created from your system, or the customer contacts the carrier.
• Whether the return gets its own tracking number and is linked to the original order.
• Whether a customer can return through the same pickup point the parcel was sent to.

Israel Post publishes a returns service for commerce sites. Among private carriers the common pattern is a dual shipment or a collection from the customer back to the store. The difference is not really price, it is who initiates the process - and that is exactly the difference you feel at a hundred returns a month rather than three.

Coverage: why most stores end up with both

• Dense areas get fast, comparatively cheap service from private carriers.
• Outlying towns are where the post's reach becomes an advantage.
• Customers who prefer a locker or a pickup point are already split across networks by which one they know.
• A failure at one carrier with no alternative stops the whole store.

Running several carriers is precisely the case where a delivery layer pays for itself, discussed separately in automation for e-commerce stores.

Which one should a new store integrate first?

A new store should integrate the carrier that will actually carry most of its orders, not the one with the broadest coverage. The reason is simple: the second integration is always cheaper than the first, because the data model, the dispatch gate and the event log already exist.

Signals that it is time to add a second carrier:

• A non-trivial share of orders comes from areas the first carrier covers poorly.
• Customers ask for a pickup point that is not in the existing carrier's network.
• A single outage at the carrier stopped dispatch for a full day.

It is also worth deciding in advance who chooses the carrier for each order. An automatic rule by postcode or region beats a judgement call by whoever is packing, because a judgement call cannot be analysed afterwards and cannot be handed to a new employee. Once the rule lives in the system you can also measure it: how many orders went to each carrier, and what each one's failure rate is.

Sources

• Israel Post - e-commerce services for business customers
• HFD - technology solutions
• Ship OS - supported courier companies