Print your first ZPL shipping label with RocketPrint

You do not need a new printer, an inbound firewall rule, or a warehouse-side web page to validate RocketPrint. You need one machine that can already print to the target device, one API key, and one complete label.

This walkthrough uses ZPL because raw printer languages are the cleanest path for thermal labels: the bytes your application sends are the bytes the printer receives. If your workflow produces PDF instead, the same job model applies, but the station will hand the document to the operating system's print path.

1. Create an API key

Sign in to the RocketPrint console, open API Keys, and create a key. It is shown once and stored only as a hash after that, so put it in the secret store used by your application.

For a local shell session:

export ROCKETPRINT_KEY="rp_live_..."

Use a separate key per service or environment. That gives you a narrow rotation boundary if one credential is exposed.

2. Install and sign in to RocketPrint Station

Install RocketPrint Station on a machine that can already see the label printer. Sign in with a RocketPrint user account and select the organization that owns the workflow.

The station enumerates printers exposed by the operating system, registers them with RocketPrint, and opens an outbound connection for work. Nothing on the internet initiates a connection into the building.

List the printers registered to your organization:

curl https://rocketprint.io/api/v1/printers \
  -H "X-API-Key: $ROCKETPRINT_KEY"

Choose the id for the target thermal printer. Store that stable printerId with your own location, workstation, or packing-station record rather than asking an operator to choose it on every order.

3. Prepare one complete ZPL document

A ZPL label starts with ^XA and ends with ^XZ. This minimal example prints a readable test rather than a production shipping label:

^XA
^FO50,50^A0N,42,42^FDROCKETPRINT TEST^FS
^FO50,115^A0N,28,28^FDORDER 1042^FS
^XZ

RocketPrint accepts raw content as base64 so the JSON request stays unambiguous. Encode the exact bytes without adding an unintended trailing newline:

ZPL='^XA^FO50,50^A0N,42,42^FDROCKETPRINT TEST^FS^FO50,115^A0N,28,28^FDORDER 1042^FS^XZ'
CONTENT="$(printf %s "$ZPL" | base64)"

4. Create the print job

Give every business print an idempotency key derived from the thing being printed. An order ID plus a document purpose is usually better than a random value because a worker retry can reproduce it.

curl -X POST https://rocketprint.io/api/v1/print-jobs \
  -H "X-API-Key: $ROCKETPRINT_KEY" \
  -H "Idempotency-Key: order-1042-shipping-label" \
  -H "Content-Type: application/json" \
  -d "{
    \"printerId\": \"YOUR_PRINTER_ID\",
    \"contentType\": \"raw_base64\",
    \"content\": \"$CONTENT\"
  }"

The API validates and persists the job before attempting delivery. Keep the returned job ID. It is the durable handle for support, status checks, cancellation while pending, and your own audit trail.

If the station is online, the job can advance immediately. If it is offline, the request still succeeds and the job remains pending until the station reconnects.

5. Read the outcome honestly

Query the job with the same API key:

curl https://rocketprint.io/api/v1/print-jobs/YOUR_JOB_ID \
  -H "X-API-Key: $ROCKETPRINT_KEY"

A normal path is:

pending → dispatching → sent → printing → completed

completed means the station's print command succeeded after the operating system accepted the work. It does not mean a sensor proved that a readable label left the printer. Paper-out conditions, a dirty printhead, a jam after spooling, and an operator placing the label on the wrong box remain physical-world concerns.

That boundary is important. Build alerts from failed, retain the job ID beside the order, and use a downstream scan when your process requires proof that a particular barcode reached a particular package.

6. Prove the retry behavior before integrating

Send the identical request again with the same idempotency key. RocketPrint returns the original job rather than creating a second label. If you reuse the key with different content, the API rejects it with a conflict instead of guessing which payload you intended.

Test this deliberately. Timeouts happen between systems, and the safest retry behavior is behavior you have already observed before a busy shift.

Where to go next

Once this single label works, replace the test ZPL with the output from your shipping or order system and move the request into a background worker. Keep the printer mapping in your database, make the idempotency key deterministic, and poll the job until it reaches a terminal state.

The quickstart contains the copy-paste path, while the reliability model defines every state and failure boundary in detail.