What remote print job statuses actually mean

The least useful status a remote printing system can return is success.

Success at which boundary? The API accepted JSON. A queue persisted the bytes. A station received them. An operating system accepted the print command. A printer moved media. A scanner read the barcode. Those are different events separated by networks, processes, drivers, cables, and physical hardware.

RocketPrint exposes a state machine because applications need to know which boundary has been crossed and which failures are still possible.

Pending: accepted and durable

pending means the API validated the request and stored the job. This is the first durable point in the workflow.

The target station may be online or offline. If it is offline, the job waits without requiring your application to keep retrying. Your system can store the RocketPrint job ID and continue with other order work.

This state is also the cancellation boundary. A pending job can be canceled. Once dispatch begins, cancellation is no longer safe because the job may already be moving toward a physical device.

Operationally, a job that remains pending deserves context rather than an immediate failure alarm. Compare its age with station presence. A five-second pending job during a reconnect is normal; a two-hour pending shipping label may be stale even if the queue is behaving exactly as designed.

Dispatching: one worker owns the attempt

dispatching means one dispatcher has leased the job. The lease prevents two server processes from delivering the same record at the same time.

This is an internal coordination state, but exposing it makes ambiguous delays diagnosable. If a job is pending, it has not been claimed. If it is dispatching, server-side delivery work has begun.

Applications should not create a replacement job because this state lasts longer than expected. Continue querying the same job. A new job is a new physical instruction.

Sent: the station received the job

sent means the job crossed the network boundary and reached the RocketPrint Station that registered the target printer.

It does not mean the local print command ran, and it certainly does not mean paper moved. It tells you that the cloud-to-station path worked and narrows investigation to the station, operating system, driver, or printer side.

If your support view shows the station online and the job sent, asking whether the API request arrived is no longer the most useful question.

Printing: the operating system accepted the work

printing means the station handed the content to the local print path and that path accepted it.

For raw label languages, the station sends bytes without asking a document renderer to reinterpret them. For document formats, the operating system and driver participate in scaling, margins, and queue behavior.

The name describes a software boundary, not a sensor reading. The print system can accept work while a device is paused or about to run out of media.

Completed: the print command succeeded

completed is deliberately narrower than “a correct label is attached to the correct package.” It means the station's print command returned successfully.

RocketPrint can support that claim with process behavior. It cannot support stronger claims without evidence from outside the print command. A completed job cannot prove:

• paper or label stock was present for the final item;
• ribbon transferred cleanly or a thermal printhead was clean;
• a barcode is readable;
• the operator took the right label;
• the label was placed on the intended package.

If the business process needs those guarantees, add a downstream scan. A barcode scan at pack-out proves something different and more valuable than a successful spool command.

Failed: a known error stopped the path

failed is terminal. The job retains a failure reason so an application can distinguish an unsupported format, a rejected queue, an unavailable local path, or another known error.

Do not automatically create a new job for every failure. First decide whether retrying the same physical instruction is safe. A failure before the local print command is different from an unknown outcome after a process interruption.

When retrying is appropriate, create the recovery workflow around the original business identifier and preserve the failed job ID for diagnosis.

Canceled: intentionally stopped before dispatch

canceled is terminal and available only while a job is pending. That rule prevents the API from claiming it stopped work that may already be on a station or in an operating-system queue.

Cancellation matters after long outages. If a station was disconnected for a day, blindly reconnecting it could release a day of stale labels. Review or cancel time-sensitive pending work before bringing it back.

Build your application around terminal and nonterminal states

The useful grouping is often simpler than the full diagram:

Group	States	Application behavior
In progress	pending, dispatching, sent, printing	Keep the original job ID and continue observing
Terminal success	completed	Record the software outcome; use downstream proof if required
Terminal exception	failed, canceled	Stop polling and route to an explicit recovery path

Transitions move forward. A terminal job does not return to printing, and an old failure does not mutate into a later success. That immutability gives support and billing one stable history.

The result is not a magical view into the physical world. It is a precise contract across the parts RocketPrint can observe—and a clear line around the parts it cannot.

Use the API reference for response fields and the reliability page for retry, queue, and limit behavior.