Drivers are machine-specific
A backend cannot reproduce every local queue and driver combination.
PDF & document printing
Send documents to the driver that already prints them correctly.
For packing slips, invoices, pick lists, and other documents, RocketPrint Station uses the local printing path and the driver already installed on that computer.
Cloud request, local driver
Your backend does not need to know the printer's hostname, operating system, or driver API.
The operational gap
Documents need local rendering without local application code.
The driver and paper configuration live beside the printer, while the business event that creates the document usually lives in the cloud.
Downloads are unfinished work
Generating a PDF does not choose a printer or confirm that the local print command ran.
Mixed output is normal
One workflow may need a raw thermal label and a driver-rendered packing slip.
The RocketPrint path
Keep document generation in the backend and rendering at the printer.
RocketPrint moves the document and intent; the station computer keeps responsibility for its installed print system.
Generate the document
Produce the PDF or text in the service that owns the order, invoice, or work item.
Encode and route
Send pdf_base64 or text with the destination printer ID and job title.
Inspect the job
Use the returned job ID to see whether the local print system accepted or rejected it.
What changes
One workflow can drive both document and thermal queues.
Existing printer setup
Paper size, trays, and drivers remain on the computer where they are already managed.
Backend initiated
No browser window or downloaded-file watcher is required.
Shared lifecycle
Document jobs use the same statuses and retry model as raw jobs.
Clear boundary
Completed means the print command succeeded, not that a sensor verified paper exited the device.
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.