ShipOS or a Direct Courier API: How to Decide Between a Delivery Layer and Your Own Integration

ShipOS is an Israeli delivery-management platform that sits between a store and the couriers: you integrate once with ShipOS, and it talks to the carriers. Its site lists Cheetah, HFD, Tapuz, YDM, Cargo, Orian, ZigZag and Wolt Drive among others. A direct courier API earns its cost when one carrier carries most of your volume.

What a delivery layer actually replaces

A delivery layer replaces three things, not one:

• The per-carrier code. Instead of three integrations with three authentication schemes and three payload shapes, there is one connection.
• The status translation. Every carrier describes the same reality in its own vocabulary. The layer maps them all into one model your store can show a customer.
• The maintenance when the carrier side changes. A change on the carrier's side is absorbed by the layer vendor rather than by you.

What it does not replace is the commercial relationship. ShipOS's per-carrier pages state plainly that connecting requires an existing account with that carrier, and in some cases connection details supplied by a carrier representative - for Cheetah, a connection code and an authentication token entered in the licences screen. Rates, service levels and coverage remain your negotiation.

What does ShipOS connect to, and what do you still have to arrange yourself?

ShipOS publishes a couriers index in which every carrier gets its own page listing the capabilities supported for that carrier. That per-carrier detail matters more than the list of names, because the capabilities are not identical across carriers. The Cheetah page lists home delivery, pickup-point support, dual shipments, bulk label printing and cash on delivery. The HFD page adds collection from the customer back to the store, and shipment cancellation.

Four things stay yours after connecting:

1. Opening an account and agreeing rates with each carrier you intend to dispatch to.
2. Obtaining the connection credentials from the carrier and entering them in the platform.
3. Deciding which carrier service maps to which shipping method in the store checkout.
4. Handling exceptions: a rejected dispatch, an address that could not be found, a parcel that came back.

This recurs in every Israeli courier API integration: the technical part is usually the short part.

Aggregation layer versus a direct carrier API

That last row is the crux. Most Israeli couriers publish no public API specification you can read before committing. The spec arrives from the carrier after an account is opened, sometimes after a signature. A direct integration therefore cannot be fully designed up front - it can only be estimated.

When is a direct integration the better build?

Four situations where the layer stops paying for itself:

• One carrier carries most of the volume. The layer's value is multi-carrier. With a single dominant carrier you are paying for an option you do not exercise.
• You need a field the layer does not expose. A special collection instruction, a courier note, a packaging type, a time window. If the carrier supports it and the layer does not pass it through, there is no way around it.
• The flow does not start in the store. When orders originate in an ERP or a production system rather than a storefront, the natural connection is system-to-carrier, as in connecting an online store to an ERP.
• Volume makes the fee material. At low volume the pricing model is uninteresting. At high volume it becomes a budget line worth calculating against a one-off build.

And one situation where staying on the layer is almost always right: three or more carriers, switched by region, price or load.

The costs that do not show up in the comparison

• Switching cost. A direct integration to a carrier you drop is code you delete. A layer you drop is a setting you change.
• Diagnosis cost. When a parcel is stuck, a layer adds one more party to ask before anyone knows whose fault it is.
• Training cost. A support team that sees one screen learns one screen. A team that sees three carrier portals learns three.
• Re-mapping cost. A unified status model is convenient until your store needs to distinguish two states the layer merged into one. That mapping then gets rebuilt on your side anyway.

What breaks in each model

On a layer: a capability exists at the carrier but is not exposed; a status the carrier sends is swallowed during normalisation; an outage at the vendor stops dispatch to every carrier simultaneously rather than one.

On a direct integration: every carrier needs its own failure handling; adding a fourth carrier is a project rather than a setting; an undocumented change on the carrier side surfaces when shipments stop going out, not before.

Both models break the same way in the end. If the order does not carry a stable shipment identifier and an event log, nobody can reconstruct what happened. The same applies to automating shipping labels in Israel, where a duplicate label is the symptom and the missing identifier is the cause.

What to decide before you choose

• How many carriers will genuinely be in use over the next year, not how many are supported.
• Which carrier-specific fields are critical to your process rather than merely nice to have.
• Who maintains the code if you build direct, and what happens when that person is unavailable.
• Which status model the customer sees, and which states you cannot afford to lose.
• What the exit looks like from each option, before you need it.

Sources

• Ship OS - delivery management platform
• Ship OS - supported courier companies