zplCloud Blog
A Complete Label Workflow in an Afternoon, with a Google Spreadsheet as the Database
Printer → design → sheet → Print View. Including the Apps Script that actually authenticates.
Start with the data source you already have
Most label projects do not stall on the printer or the design. They stall on data: someone has to own the article list, and "we'll connect the ERP" turns into a six-week ticket.
So start with a Google Spreadsheet. It is a real data source, everyone in the office can edit it, and the path from there to a printed label is short. When the ERP connection is eventually ready, the label and the print path do not change - only where the rows come from.
This is the whole chain, end to end.
1 - Printer on the network and connected
Unbox, load media, power on, get it on the network, then connect it to zplCloud with the Weblink one-liner or the CLI agent, and apply a printer profile so darkness and speed match the media. That is covered step by step in the speed-run post; budget 10 minutes.
2 - Design the label
In the designer, start from a template or blank and add the fields that change per label: article number, name, quantity, destination. Name the bindings exactly like the spreadsheet column headers - that one decision removes all the mapping work later.
Check the preview as PNG, PDF or SVG. It is rendered server-side by the same engine that produces the ZPL, so it is not an approximation.
Note the design ID. It is <name>.<id>, e.g. shipping-label.42; you need it for the API.
3 - The spreadsheet
One row per label, one column per binding:
| artikel_nr | name | menge | ziel |
|---|---|---|---|
| 4006381333930 | Cable tie 200 mm | 50 | Ramp 4 |
| 4006381333947 | Cable tie 300 mm | 25 | Ramp 2 |
Path A - no code. Copy the rows into the designer's Test Data tab or into a batch job and print. This is enough for a weekly print run and takes no setup at all.
Path B - Apps Script. The sheet becomes the trigger. Render through the public API with an API key:
// Extensions → Apps Script. Renders the active row and returns ZPL.
const API_KEY = 'sk_zplcloud_…'; // API tab in the platform
const DESIGN_ID = 'shipping-label.42'; // "<name>.<id>"
function renderActiveRow() {
const sheet = SpreadsheetApp.getActiveSheet();
const header = sheet.getRange(1, 1, 1, sheet.getLastColumn()).getValues()[0];
const row = sheet.getRange(sheet.getActiveCell().getRow(), 1, 1, sheet.getLastColumn()).getValues()[0];
// The body is an array of records: keys must match the design's bindings.
const record = {};
header.forEach((col, i) => record[col] = row[i]);
const res = UrlFetchApp.fetch(
'https://api.zplcloud.com/v1/zpl/render/design/' + DESIGN_ID,
{
method: 'post',
contentType: 'application/json',
headers: { 'X-API-Key': API_KEY },
payload: JSON.stringify([record]),
muteHttpExceptions: true // otherwise a 4xx throws before you can read the message
});
if (res.getResponseCode() !== 200) throw new Error(res.getContentText());
return res.getContentText(); // the ZPL
}
Two limits to design around, both enforced by the API:
- 500 records per request - split larger runs into chunks.
- 1 MB request body - with normal label data that is thousands of rows, so the record cap binds first.
Add a custom menu (onOpen → SpreadsheetApp.getUi().createMenu(...)) and your colleagues get a Print entry in the spreadsheet's own menu bar.
4 - Getting the ZPL to the printer
Rendering and printing are two steps on purpose - you can render now and print later, or render once and print on three sites.
- From the platform: the design prints to a Weblink or agent printer with one click, no script involved.
- From your own code: send the ZPL to the printer over TCP 9100 through the agent, or hand it to CloudToBrowserPrint on the operator's machine.
- For a person: skip the script entirely and give them a Print View (next step).
5 - Print View for the people who actually print
Create a Print View from the design, mark menge and ziel editable, lock artikel_nr, and back the view with the spreadsheet data or a lookup. Share the URL or print the QR code and tape it next to the printer.
The operator opens the link on a phone, scans the article barcode into the field, checks the live preview and taps print. No app, no training.
The whole chain
| Stage | What | Time |
|---|---|---|
| 1 | Printer + Weblink/agent + profile | ~10 min |
| 2 | Design with bindings named like the columns | ~5 min |
| 3 | Spreadsheet, optionally an Apps Script | ~5 min |
| 4 | Print path (platform, API or Print View) | ~2 min |
| 5 | Operator scans and prints | seconds |
Why a spreadsheet is a defensible choice
It is not a compromise you apologize for. A sheet gives you versioning, comments, per-user access and an audit trail out of the box, and no one needs onboarding. Its real limits are concurrency and referential integrity - when two people edit the same row during a shift, or when the article list has to match the ERP exactly, that is the signal to move to the data hub and query SQL Server or MongoDB directly.
The migration is contained: same design, same bindings, same Print View. Only the data source changes.