Automating Shipping Labels From an Israeli Store: The Real Bottlenecks

Printing a label from an API is usually one call. What consumes the time on these projects is three other things: Israeli addresses that do not parse, labels created twice, and Hebrew that reverses on the sticker itself. Each costs more than the integration.

The real bottleneck: addresses

This is the problem that most surprises people, and it is not technical - it is in the form.

A carrier needs a structured address: city, street, number, sometimes apartment and floor. Many Israeli stores collect the address as one free-text field, and what goes in looks like this:

• A street and number with a city, no comma, no floor
• Street, entrance, apartment and city all in one field
• next to the supermarket, white building - said in earnest
• A locality with no street names at all

No automatic extraction will solve this reliably, and trying to parse it in code is a trap: it will work for 80% and fail silently on the rest, and a silent failure on a shipping label means a parcel that never arrived.

The fix is in the form, not the code

That is a change to the checkout experience and therefore needs the owner's approval - a conversation worth having before writing a line of code, because without it everything else rests on broken data.

And for existing orders: there is no shortcut. An address stored as free text will need a human touch. Better to plan a review queue than to assume a script will clean them.

A duplicate label - why it is worse than an ordinary duplicate

Creating a label is not creating a document. With most carriers it creates a shipment in their system - a tracking number, sometimes a charge, sometimes a scheduled collection.

So a label created twice is not a spare file. It is a second shipment somebody must cancel by hand, and sometimes a charge to correct.

The ordinary scenario: the button was clicked twice, or the call timed out and the code retried.

The three defences:

1. A unique key from the order. Before creating, check whether a label already exists for it.
2. Store the tracking number immediately on receipt, before anything else.
3. A timeout is not a failure. Do not retry automatically - check whether the shipment was created.

Exactly the same logic as issuing tax documents: an operation creating a real-world commitment does not tolerate a blind retry.

Hebrew on the label

A point discovered at the first print rather than before it.

The label is printed through the carrier's system, not yours. You send a name and address; what appears on paper is rendered by them. So every Hebrew and RTL problem applies - and you have no control over them.

What breaks in practice:

• A name with a number - an apartment number inside a Hebrew address line. The digits can jump.
• Quote marks in Hebrew abbreviations - sometimes disappear or break.
• Truncation - a long field cut mid-word in Hebrew.

What to do: test before promising. Print one real label with a full Hebrew name, a Hebrew street, a house number and an apartment number - and look at the paper. Not the on-screen preview; the label.

If it breaks, shortening or splitting fields usually helps. But you need to know that before the client prints forty.

Batch, not order by order

The temptation is to create a label the moment an order is paid. That does not match how packing works.

In a real business somebody sits down, packs a few dozen orders, and prints. If labels were created in the morning and an order was cancelled since, there is a label for a shipment that will not happen.

The pattern that works:

1. The order is paid and marked ready to pack.
2. A packing screen shows what is waiting.
3. The operator selects a group and clicks once.
4. Labels are created in a batch, and tracking numbers are stored on the orders.
5. One file to print.

The benefit: the label is created close to when the parcel actually leaves, and cancelled orders are already off the list.

What must be in place

• An error queue a human sees. An order that failed label creation - because of an address - must appear where someone looks each morning. An order stuck in a log is an order that did not ship.
• What happens on cancellation. If a label was created and the order was cancelled, somebody needs to know there is an open shipment.
• Store the tracking number on the order - that is what connects this to tracking.
• Do not lose the file. A label created whose PDF was lost is an open shipment with no paper. Store a link.

What it is worth - and when it is not

The real saving is typing addresses into the carrier's website by hand. Three minutes an order, including the typing errors that produce deliveries to the wrong address.

The number that decides: shipments per day.

• Ten a day - half an hour manually. An integration with its maintenance is close to the line.
• Fifty a day - two and a half hours. Clearly worth it.
• Under five - do not build. And that is a legitimate answer worth giving the client.

And worth mentioning: fixing the address form alone delivers a substantial share of the value - fewer errors, fewer redeliveries - with no integration at all. If the budget is limited, that is what to do first.

Checklist

1. Fix the address form before anything - separate fields, locality from a list.
2. Plan a review queue for existing broken addresses.
3. Idempotency: a key from the order, a check before creation.
4. Print a real label with full Hebrew and look at the paper.
5. Batch at packing time, not at payment.
6. Store the tracking number and a link to the file on the order.
7. Count shipments per day before pricing.