PDF adds a conversion
Redrawing a native thermal label introduces another place for size and barcode fidelity to change.
Shipping labels
Send carrier-native labels straight to the thermal printer.
Ask the carrier for ZPL, base64-encode the response, and send it to the printer at the pack bench. RocketPrint passes raw printer languages through untouched.
Carrier ZPL in, native ZPL out
No rasterization step between the label API and the thermal printer.
The operational gap
The label already exists. It just needs to reach the right bench.
Carrier APIs solve rate shopping and label generation. Production printing still needs a reliable bridge into the warehouse.
Browser flows need a person
Someone has to choose a destination and dismiss a dialog for every shipment.
Retries can waste stock
A webhook delivery or worker retry must not automatically create a second label.
The RocketPrint path
Buy, map, print.
Keep label purchase in the carrier integration you already use and make RocketPrint the final delivery step.
Request ZPL
Ask EasyPost, ShipStation, or your carrier for the printer-native label when available.
Choose the bench
Map the order location to the RocketPrint printer ID stored for that bench.
Send one job
Create a raw_base64 job with an idempotency key derived from the shipment ID.
What changes
Automation without compromising the label path.
Native rendering
The printer interprets its own language at its own resolution.
Bench routing
Location logic remains a normal lookup in your application.
Queued delivery
Labels wait safely while a station is offline.
Traceable jobs
Store the RocketPrint job ID next to the shipment record.
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.