Scan-to-Label in 5 seconds: Engineering behind the speed USP
Karl is built for Shopify stores shipping from Germany and Austria; the carriers named in this article (DHL, DPD, UPS, FedEx) are the ones Karl connects there.
"Scan-to-label in under 5 seconds" is on the Karl main page. This post explains the architecture decisions that let us hit this in a well-tuned warehouse workflow, from scanning the order barcode to the thermal printer dropping the shipping label.
The problem with classic shipping workflows
A typical Shopify warehouse workflow without specialisation looks like:
- Operator opens the shipping app in a browser
- Manually searches for order number (or scans barcode)
- Picks carrier from dropdown
- Picks service level from dropdown
- Clicks "Create label"
- Waits for carrier API response
- Clicks "Print"
- Picks printer (if not preset)
This realistically takes 25-60 seconds per parcel. At 500 parcels a day, worst case that's 8 hours spent on click work. Plus: 6 manual decisions are 6 possible error sources (wrong carrier, wrong weight, wrong service).
Karl's architecture: three tricks
1. Routing is computed before the scan
As soon as a Shopify order comes in, Karl triggers the routing algorithm asynchronously. Carrier and service are determined via smart routing rules and stored in Karl's cache. Surcharge lists are pre-checked as well. When the warehouse operator scans the barcode hours later, the "which carrier, which service, what price" decision has already been made. Latency cost of this step at scan time: 0 ms.
2. Carrier API call is triggered speculatively
As soon as the order is "paid + parcel weight known", Karl pre-requests the label from the chosen carrier and holds it locally. When the operator scans, no new carrier API call is triggered: the label is served from cache. The carrier round-trip is out of the critical path.
3. Printer push via WebSocket instead of PDF download
Classic shipping apps send the label as a PDF to the browser, the operator clicks "Print", the OS opens a printer dialog. That's ~3 seconds of overhead with required clicks.
Karl keeps a WebSocket open to the warehouse PC (or directly to a network-capable thermal printer via IPP). On the scan event, the cached label is WebSocket-pushed directly to the printer: no browser, no PDF, no click. The printer prints as soon as the bytes arrive. What else Karl brings to printing shipping labels in Shopify (bulk label printing, auto-print, all 7 carriers) is on the feature page.
Where the seconds in the workflow really sit
In a well-tuned workflow, the software steps from "barcode scan" to "label rolls out of the printer" are sub-second territory: the routing lookup is cached, the label is pre-computed, and the print push goes over a standing connection to the warehouse printer. The longest variable is regularly the physical print itself plus network latency between the warehouse PC and the cloud app. Without the click chain in front (open app, find order, choose carrier, …), the bottom line ends up in the ballpark of 5 seconds: the larger part of that is hardware, not API calls.
Why it matters economically
The size of the saving depends on your concrete workflow. A simple illustrative calculation: if a shop ships 1,000 parcels per day and the workflow saves 25 seconds per parcel, that's roughly 7 hours of labour per day not spent on click work. Plus: fewer manual mistakes in carrier and service selection, because routing is already decided automatically when the order comes in. If you want to ship orders straight out of an ERP or WMS, the same core is available through Karl's shipping API: compare rates and create labels without going through the interface.
If you want to pilot Karl in your own warehouse: the app is on the Shopify App Store. Scan-to-label is already in the Start plan, and Start has no monthly fee: €0 a month, €0.25 per label, for domestic shipping.