Cheetah Delivery: Creating Shipments and Tracking Them from Your Own System

Cheetah Delivery (צ'יטה שליחויות) is an Israeli e-commerce courier that operates the Cheetah Shops pickup network alongside home delivery, international shipping and customs brokerage. From the order system's point of view, a Cheetah shipment is a record born from a snapshot of the order, which then lives its own life separately from that order.

Cheetah's own systems, and what a store actually connects to

Cheetah presents several distinct services on its site: domestic delivery, international shipping, the Cheetah Shops pickup network, customs brokerage and a Cheetah CX platform, with separate customer portals for viewing and tracking.

What is not on the site is a technical specification. No endpoints, no field names, no message structures are published. Anyone searching for "the Cheetah API" finds two genuine routes instead:

• A plugin or an intermediate platform. Ready-made interfaces exist - on ShipOS, and in the Konimbo plugin catalogue - that perform the dispatch to Cheetah on your behalf.
• Contacting Cheetah directly. Connecting an in-house system means asking the company and receiving the connection details for your account.

Both routes start in the same place: an active account with Cheetah. There is no technical path that bypasses the commercial one.

The shipment record: a snapshot, not a live view of the order

The common mistake is to build the shipment screen as a view over the order. It looks correct right up to the moment a customer changes their phone number and the screen shows a number that was never sent to Cheetah.

A correct shipment record holds, as its own fields:

• Recipient name, phone and address exactly as they were at creation time.
• The chosen service type and the parcel count.
• The pickup point identifier, when one was selected.
• The tracking number returned.
• The identifier of the order it was created from.
• An event log with timestamps.

The result is that "where was this actually sent" is answered from the record rather than reconstructed. The same principle drives automation in logistics, where every operational document is a sealed snapshot instead of a mirror of live data.

How do you actually connect a store to Cheetah?

1. Open a commercial account with Cheetah and agree rates and coverage areas.
2. Ask a Cheetah representative for the connection details - on the ShipOS route, a connection code and an authentication token.
3. Enter those details in the platform or plugin, and map every checkout shipping method to a Cheetah service type.
4. Dispatch one test shipment, confirm a tracking number comes back, print the label and check that the status updates.

Step four is the only one that surfaces mapping mistakes. A single test shipment costs very little and exposes almost everything.

Cheetah Shops: a pickup network that changes underneath you

The Cheetah Shops network is reported at over 1,300 pickup points nationwide, and it is not static. Points close, change hours and change address.

Hence three rules:

• Store the point identifier, not just its name. Names change; identifiers persist.
• Also store the address shown to the customer and the moment of selection, so you can explain later exactly what they chose.
• Never silently re-match to a different point. If the chosen point is unavailable, go back to the customer for a new choice.

Point selection itself is a broader problem, handled separately in lockers and pickup points in Israel.

Returns and the dual shipment

In Israeli e-commerce a return or exchange is usually represented as a dual shipment: an outbound and an inbound parcel linked together. The ShipOS page for Cheetah lists dual-shipment creation as supported.

What that means in data terms:

• The return leg is a new record with its own tracking number.
• The link between the two lives in a dedicated field, not in a free-text note.
• The order status does not move backwards. It moves forward into "returning" and then "returned".
• The refund is a separate event conditioned on receiving the item, not on a shipment status.

What happens when the customer changes their address after the shipment exists?

The short answer is that your system cannot change it alone. Once the shipment is created, the binding address lives at the carrier, and often on a label that has already printed.

The flow that works:

• The order locks its shipping fields at dispatch and renders them read-only.
• A change request is recorded as an event on the shipment, with who asked and when.
• The team checks with Cheetah what is possible given the parcel's actual status.
• If nothing can be changed, cancel and create a new shipment, keeping the link between the two.

The event table your support team actually reads

That table is also the responsibility split for the project. Every row whose source of truth is the carrier cannot be corrected from your system, and every row whose source of truth is you has to be reconstructible without asking anyone.

What to have ready before you connect

Six things, prepared before development starts, remove most of the delay:

• An active Cheetah account with the service types you intend to use genuinely enabled.
• A complete mapping between checkout shipping methods and the service types on that account.
• A shipments table separate from the orders table, with its own shipment identifier.
• An event log able to hold the carrier's raw value alongside your internal status.
• A decision on who may cancel a shipment and who may only request a cancellation.
• The business's fixed return address, for return legs and dual shipments.

The last item looks trivial until it turns out to be missing on the day the first return is created, at which point somebody types an address by hand that nobody ever checked.

Sources

• Cheetah - shipping and logistics
• Ship OS - Cheetah Delivery store connection