---
title: "How to print shipping labels from several warehouse stations without losing or double-printing labels"
description: "When several warehouse stations print shipping labels from the same orders, the safe design is one print queue in which downloading a label is the act that removes it from every station's queue. We route each label to one station with a single shared rule, filter before we download, mark as printed everything we export by any other path, and send a batch as one complete document. Every lost or double-printed label we had came from a download that happened in the wrong place or at the wrong time."
date: 2026-10-11
lang: en
canonical: https://goingstellar.ro/methods/label-printing-several-warehouse-stations/
author: Going Stellar
publisher: GOING STELLAR S.R.L.
topic: E-commerce / Label printing
license: CC BY 4.0
alternate_ro: https://goingstellar.ro/ro/metode/printare-etichete-mai-multe-statii-depozit/
---

# How to print shipping labels from several warehouse stations without losing or double-printing labels

*When several warehouse stations print shipping labels from the same orders, the safe design is one print queue in which downloading a label is the act that removes it from every station's queue. We route each label to one station with a single shared rule, filter before we download, mark as printed everything we export by any other path, and send a batch as one complete document. Every lost or double-printed label we had came from a download that happened in the wrong place or at the wrong time.*

> E-commerce · Label printing · 2026-10-11 · https://goingstellar.ro/methods/label-printing-several-warehouse-stations/

## Key points

- In a multi-station warehouse, the download of a shipping label should be the single act that removes it from every station's print queue.
- Filter labels by station and by parcel status before downloading them, because a download is a write that hides the label from every other station.
- Every path that exports labels, including manual ones, must mark them printed; otherwise the print queue fills with parcels already delivered and stops being usable.
- Downloading labels one at a time isolates failures and lets you regroup PDFs without downloading again, while batch PDF generators are slow and fail as a whole batch.
- A batch sent to the warehouse should be one complete, verified document, not a document followed by corrections.

## What a multi-station print queue is

A multi-station print queue is the list of shipping labels that have been created but not yet printed, shared by several packing stations, where each station sees only the labels for the goods it holds. To print labels from several stations without losing or double-printing any, keep one queue, treat the download of a label as the act that removes it from every station's queue, and route every label to exactly one station with one rule that all tools import.

In our warehouse, the queue is the set of labels in the shipping integration whose *downloaded* flag is still false. Downloading a label sets the flag. That flag is the whole coordination mechanism between stations: a station that sees the flag set skips the label, because another station already has it.

## Step 1: one routing rule, imported everywhere

Each station sees only the stores and products it holds. Our rule decides a label's station from the **first SKU** of the order: one product family goes to one station, everything else to the other. An order has one label, so it goes whole to one place. We measured how often that rule splits goods across stations: in a window of 14 days, of 482 orders with labels, 6 had more than one SKU and 1 would have needed goods from both stations. It is rare, but then one station receives a label for goods it does not have.

The routing rule lives in one module and every tool imports it: the station queue, the morning batch job and the server. Two copies of a routing rule are two truths, and they drift the first time the warehouse changes its split. Stores shared between stations appear at both, which is why the print command re-reads each order fresh just before downloading and skips what the other station has already taken.

## Step 2: look freely, download only to print

The station tool has three verbs with very different effects. **pull** refreshes the station's queue from the shipping integration, in about 15 seconds. **plan** answers from that cache instantly, with no effect at all: how many labels, per store, per SKU, per category. **open** is the only mutation: it downloads the filtered labels, merges them into one PDF, opens it in the browser on the station and records the batch as printed. The tool does not print by itself; the operator presses Ctrl+P.

The operator does not type commands. The operator asks in plain language ("how many labels do I have to print?") and an AI agent on the station runs `pull` and `plan` and answers with the number. Batches are capped at 250 labels, because the browser and the printer do not cope with one enormous PDF.

**Filter before you download.** Our morning batch job, which sent labels for a few stores to a group chat, downloaded first and filtered by station afterwards. Every download set the flag, so the job quietly stole labels from the other station's queue: they showed as downloaded without ever being printed there. After the fix, a real run sent 6 labels to one station and left 14 in the other station's queue. The same job had a `--dry` mode that downloaded before checking the flag, so a listing command had an irreversible effect. A dry run must stop before the first write.

## Step 3: send only parcels that have not left

A label that exists is not a parcel waiting to leave. The morning job originally sent every label not sent before, and on one day 11 of the 27 labels it sent belonged to parcels already in transit. Now the job asks the courier for each label's status and sends only labels whose parcel has not been picked up yet.

**Fail open, but loudly.** If the tracker does not answer or does not know the label, the label is sent anyway, with a warning line in the log. One extra label is an annoyance; one missing label is a parcel that does not leave. Records of what was sent are written per batch and only after that batch was delivered, so a failed send to one station is retried at the next run without resending the batch that went out.

## Step 4: every other export must mark the label printed

Any path that gets labels out of the system has to mark them printed, not only the station tool. We broke this rule ourselves: when we produced labels for the warehouse by hand, we downloaded them and never marked them. Measured over 90 days, the order system's print queue held 112,003 unprinted labels, and 79,913 of them already had the parcel scanned by the courier, so they had been printed somewhere. A queue in which 71% of the rows are parcels already with the customer is useless: nobody can tell what is left to print. For one store, 443 labels were unprinted and 0 had ever been marked printed, because all of its labels had gone out through us.

The fix is to use the system's own print function, which merges the PDFs, sets the printed time and writes an audit log of who printed which label and when, in one step. For the retroactive clean-up the safe criterion is that the parcel moved: if the courier scanned it, someone printed it. Labels that have not moved are left alone, because those really are waiting to be printed. Never mark printed a label you did not actually download.

## Fetch labels one at a time, and keep the queue on a server

Downloading labels from the shipping integration's interface felt slow, but the API was not slow. The batch PDF generator took 10 to 20 seconds per batch, so 41 batches took about 10 minutes. The per-label link answered in 0.33 seconds, and 405 labels took 2.5 minutes with 15 requests in parallel. Fetching per label is strictly better: failures are isolated to one label, and the saved PDFs can be regrouped as often as the warehouse wants without downloading anything again. Labels are images, so we check coverage by counting pages per order, not by extracting text.

**A crash between download and save loses labels.** Once, a process died midway and 33 labels were marked downloaded with no PDF saved. They are recovered by fetching again by order, because the per-order endpoints do not depend on the not-downloaded flag. We also do not download labels straight from the courier, even when we could: that does not clear the integration's flag, so the label would stay in the other station's queue and be printed twice.

The station tool first ran only on each station's laptop, so every rule change needed an update on every machine, and nobody could see what anyone printed. The queue now also runs on a server that imports the same code, with the same routing rule, an activity log of who printed what and when, and service accounts per station. A station without the server setting keeps working locally, as before; an unconfigured station does not break.

## Where we were wrong, and the limits

**A batch is one document.** We sent a PDF of 61 labels to the warehouse group, then found that 26 of them had a cancelled label, and followed with a correction and then a clarification: three messages for one batch, and the warehouse had to remember what to ignore. The group is a print queue, not a conversation. Now a batch is one complete, correct document; if the batch was wrong, we rebuild a clean PDF and send that, with a short factual caption (date, store, station, number of labels, order numbers). The corollary is to verify the batch before sending, because there is no cheap second chance.

**"Printing broke after the deploy" was a wrong diagnosis.** After a deploy, someone saw zero print requests and concluded the new frontend was broken; we believed it and rolled back. Later analysis showed the new frontend was fine: nobody had opened the printing page in that window. Zero requests is also what an unopened page looks like. The likely real cause was a database on the scanning service locked by a long read. Before rolling back, check in the web server log who loaded the page after the deploy, and run a headless smoke test against the live build.

This method does not guarantee that a label is physically printed: the flag records a download, and the operator still has to press print. It does not stop the rare order whose goods sit at two stations. And it depends on every tool honouring the same flag; one new export path that ignores it brings the stale queue back.

## Checklist

**1. **One queue; downloading a label removes it from every station. **2. **One routing rule, imported by every tool. **3. **Look with read-only commands; download only to print. **4. **Filter by station and parcel status before downloading; a dry run writes nothing. **5. **Every export path marks labels printed, through the system's own function. **6. **Fetch per label, save before marking, recover by order. **7. **One complete document per batch, verified before it is sent. **8. **Before blaming a deploy, check whether anyone opened the page.

## Questions and answers

### How do I stop two warehouse stations from printing the same shipping label?

Use one print queue in which downloading a label is the act that removes it from every station's queue, and route each label to exactly one station with a single rule that every tool imports. Stores shared by two stations should be re-read just before download, so a station skips labels the other already took. Do not download labels from a second source that does not update the shared flag, or the label stays queued elsewhere.

### Why are labels missing from my station's print queue?

Labels usually disappear from a station's queue because some other process downloaded them, and downloading marks a label as taken for every station. Common causes are a batch job that downloads before filtering by station, a dry-run mode that downloads before checking the flag, or a script that crashed after downloading but before saving the PDF. Recover by fetching the labels again by order number.

### Should shipping labels be downloaded in batches or one by one?

One by one, if the system offers a per-label link. In our measurements the batch PDF generator took 10 to 20 seconds per batch, while a single label took 0.33 seconds and 405 labels took 2.5 minutes with 15 parallel requests. Per-label downloads isolate failures to one label and let you merge and regroup the saved PDFs as often as needed without downloading again.

### Why is my print queue full of labels that were already shipped?

A print queue fills with shipped parcels when labels leave the system by a path that does not mark them printed, such as a manual export or a file sent to a chat group. In our case 71% of unprinted rows over 90 days were parcels the courier had already scanned. Make every export mark labels printed, and clean up retroactively by marking printed only labels whose parcel has moved.

### How should label batches be sent to a warehouse group chat?

Send each batch as one complete, correct document with a short factual caption: date, store, station, number of labels and order numbers. Do not follow it with text corrections, because the warehouse then has to remember what to ignore. If a batch was wrong, rebuild a clean PDF and send that instead, and verify the batch before sending, since a print group has no cheap second chance.

## How to cite

**Cite this as:** Going Stellar (2026). *How to print shipping labels from several warehouse stations without losing or double-printing labels*. GOING STELLAR S.R.L.. https://goingstellar.ro/methods/label-printing-several-warehouse-stations/

```bibtex
@misc{goingstellar2026label,
  title  = {How to print shipping labels from several warehouse stations without losing or double-printing labels},
  author = {{Going Stellar}},
  year   = {2026},
  url    = {https://goingstellar.ro/methods/label-printing-several-warehouse-stations/},
  note   = {2026-10-11}
}
```

Licence. Free to quote with attribution.

## Also available

- This page as HTML: https://goingstellar.ro/methods/label-printing-several-warehouse-stations/
- Same article in Romanian: https://goingstellar.ro/ro/metode/printare-etichete-mai-multe-statii-depozit/