Label printing API

• One request shape regardless of whether the target speaks ZPL, TSPL, TPCL or Epson.
• A label can also be the client: point a field group at your JSON endpoint with Bearer, Basic or API-key auth.
• Webhooks report job events back to your system instead of making you poll.
• The same operations are exposed over MCP, so an AI agent can drive printing through the identical surface.

• A physical printer still needs a LabelInn runtime near it: the PC that has the printer must be online with cloud printing enabled for that printer. The API routes the job; it does not create a network path to hardware.
• API writes (creating jobs) need Pro ($24.90/month) or the 14-day trial. Free and Starter keys can read and use the read-only sandbox quota.
• A 201 means the job was queued, not printed. Poll the job, or subscribe to webhooks, to learn the outcome.
• Limits are counted in requests, not labels: see the table below before designing a loop that sends one label per call.

1. Create a key in LabelInn under Settings, API Keys. sk_test_ keys run against a sandbox that never prints and has its own quota; sk_live_ keys send jobs to physical printers.
2. GET /v1/fleet/printers: pick a printer with is_online: true and cloud_print_enabled: true. The second flag is switched on in the desktop app by the customer; the API cannot enable it. A job for an offline printer waits in the queue.
3. GET /v1/designs/{designId}/variables: returns the exact field names and a ready-made example_payload. Keys you send that the design does not know are ignored silently, which looks identical to a binding bug.
4. POST /v1/print/jobs with payload_type: "template", then GET /v1/print/jobs/{id} about every 2 seconds until the status is terminal.

curl https://labelinn.com/v1/print/jobs \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -H "X-Idempotency-Key: order-SO-10442-line-1:1" \
  -d '{
    "printer_id": "prt_abc123",
    "payload_type": "template",
    "design_id": "dsg_shipping",
    "data": { "order_id": "SO-10442", "customer": "Maya Brandt", "barcode": "TR123456789" },
    "copies": 2
  }'

HTTP/1.1 201 Created
{
  "success": true,
  "data": {
    "id": "job_...",
    "status": "queued",
    "printer_id": "prt_abc123",
    "payload_type": "template",
    "copies": 2,
    "is_test_mode": false,
    "created_at": "2026-10-17T12:00:00Z"
  }
}

The response shape is the JobResponse / PrintJob schema of the OpenAPI file; the values above are placeholders, not output captured from the live service.

Send X-Idempotency-Key on every create. For 24 hours a repeated key returns the original job and prints nothing, which is what protects you from a double label after a network retry. A second request with the same key while the first is still running gets 409 IDEMPOTENCY_IN_PROGRESS with Retry-After; the same key with a different body gets 409 IDEMPOTENCY_KEY_REUSED.

The trap: after a job comes back failed, sending the same key again returns the old failed job instead of reprinting. Put an attempt counter in the key, for example order-SO-10442-line-1:<attempt>. A request refused with a 4xx releases its key, so a corrected request may reuse it.

The official SDKs raise a typed rate-limit error that carries the wait time; see the language pages for Python, Node.js, C# and Go.