HFD Integration: Turning Orders into Shipments and Statuses into Data

HFD is an Israeli courier and logistics company focused on e-commerce, offering same-day and next-day delivery, pickup points, E-Post automated lockers and fulfilment services. The integration that matters is not a "create shipment" button. It is a dispatch gate that guarantees one shipment per order, a tracking number that is stored, and carrier statuses translated into your own vocabulary.

What HFD publishes, and what only arrives after you open an account

HFD's site has a technology-solutions page describing six capabilities: an ETA system that tells the customer an estimated delivery time, a business dashboard for shipment control and SLA monitoring, API integration with commerce platforms, proof of delivery, multi-channel customer service, and E-Post automated lockers.

What is not on that page is a technical specification. There is no endpoint list, no field names, no status codes and no public webhook documentation. That is not a criticism - it is the norm among Israeli couriers, and the same pattern appears across Israeli courier API integration: the spec is a commercial asset handed to a customer once an account exists.

The planning consequence is concrete. You cannot commit to a delivery date for the project before the spec is in your hands. You can commit to everything that does not depend on it: the dispatch gate, the data model, the internal status vocabulary.

The dispatch gate: what must be true before an order becomes a shipment

The gate is one check that runs before the carrier call, rather than a series of corrections after it. Eight conditions worth putting in it:

1. An address with an identified city and street, not one free-text field.
2. A valid mobile number - the channel that carries notifications and locker codes.
3. Weight and parcel count, even when they are defaults.
4. The checkout service type, mapped to a service that actually exists on your HFD account.
5. A pickup point or locker when that is the shipping method, stored by point identifier and not only by name.
6. A collection amount, when the order is cash on delivery.
7. A flag that the order is paid or approved, per your own business rules.
8. A check that no open shipment already exists for this order.

The eighth is the only one that prevents the genuinely expensive failure: a double click producing two shipments, two labels and two charges. The fix is an order-level unique identifier written before the carrier call, not after it.

Which HFD capabilities force a field into your order record?

That table is effectively the field list for your shipments table. If something appears in the middle column and has nowhere to live in your database, the capability in the left column is not really supported on your side.

Statuses: raw value in, internal status out

The rule is simple. Every update from HFD is stored twice: once as the raw value exactly as received, with a timestamp, and once as the internal status your store displays.

Why this is not redundant:

• Investigating with the carrier. When you call HFD, the question is what they recorded, not what you translated it into.
• Changing the mapping. If you decide a state should map differently, you can recompute from raw values instead of losing history.
• States you did not anticipate. A carrier sends a state with no mapping. With raw values it is stored and visible; without them it disappears.
• SLA reporting. Measuring time between states needs the carrier's original timestamps, not the moment your job processed them.

A minimal internal model that works: created, collected, in transit, at pickup point, delivered, failed, returned. Seven states cover most stores, and you can show the customer fewer.

What does proof of delivery give you that a status does not?

A status says the carrier's system marked the parcel delivered. Proof of delivery says when, to whom, and against which signature. HFD names those three items explicitly as part of its proof-of-delivery service, and that is the difference between "the system says delivered" and an answer you can send to a customer who says they never received it.

Three decisions worth making up front:

• How long delivery evidence is retained, and where - inside the order or in a separate events table.
• Who on the team may see a recipient name and signature, and what the customer themselves is shown.
• What happens when a delivery is marked with no recipient name: does the order close automatically, or move to review?

Duplicate shipments, cancellations and address changes

• Duplicate shipments. Only prevented before the fact, never cleaned up after it. Unique identifier, order-level lock, and a dispatch button that disables itself once used.
• Cancellation. A cancellation is a request, not a fact. Until the carrier confirms it, the order is pending cancellation rather than cancelled.
• Address change after dispatch. Not solved by updating a field in your database. Once the shipment exists, the address lives at the carrier, and changing it is a procedure with them.
• Returns. A return is a new shipment linked to the original, not a status change on the old one.

The pattern matches every other order-side process - see how to automate order processing, where each external action is recorded as an event rather than overwriting a field.

Questions worth asking HFD in writing when the account opens

• Which connection methods are available for an account of our type, and what is required to obtain them.
• Whether statuses are pushed to us, or whether polling from our side is expected.
• Which service types are actually enabled on our account, lockers and pickup points included.
• The procedure and the time window for cancelling a shipment that has already been collected.
• The format proof of delivery arrives in, and how long they retain it.
• Who the technical contact is, and the response time when dispatch stops working.

Sources

• HFD - delivery and logistics
• HFD - technology solutions
• e-post - automated lockers