Events repeat
Return platforms and queue workers can deliver the same event more than once.
Return labels
Put the right return label in the right parcel.
When your system approves a return or prepares an outbound package, send the carrier label to the printer at the site handling that parcel.
Return ID becomes the retry key
Repeated events resolve to one RocketPrint job instead of another physical label.
The operational gap
Returns introduce another label with another identity.
A return label may be created days after the outbound shipment and printed in a different building. It needs its own routing and job record.
Sites change
The return destination or processing site may not match the original fulfillment location.
Paper is easy to confuse
A job title and linked return ID make the physical artifact traceable.
The RocketPrint path
Give the return its own deterministic print job.
Use the return record—not a timestamp—as the stable identity for the label request.
Create or retrieve the label
Get ZPL or PDF from the carrier when the return reaches the print-ready state.
Resolve the handling site
Map that site to the thermal printer that will prepare or receive the parcel.
Key the request
Create the job with an idempotency key derived from the return ID and label purpose.
What changes
A repeatable return flow without duplicate paper.
Explicit destination
Routing follows the site handling the return, not an operator's default printer.
Stable identity
The job ID can live on the return record for support and audit context.
Native or PDF
Send carrier ZPL untouched or print a PDF through the installed driver.
Offline tolerant
Approved returns can queue until the handling station reconnects.
Start with one printer
Make the physical step part of the workflow.
Install RocketPrint Station beside a printer, send one request, and keep the job ID. That is the whole path.