Bills of lading, CMR notes, packing lists and labels generated from your TMS or WMS data

You move goods and you produce the paper that goes with them: a CMR for every truck, a bill of lading per shipment, a packing list per consignment and a commercial invoice for customs. The volume is high, the wording changes with every lane and customs variant, and the people who know what the document must say are in operations, not engineering. You want documents generated from your TMS or WMS at dispatch, templates your own team edits, and nothing in the loop that waits for a release. Connect from your own code, or from Make, Zapier, n8n or Airtable if you do not have an engineering team.

You sell to the people above, and every one of your customers wants their own logo on the delivery note. Per-customer templates live in separate workspaces, each with its own branding, and you can embed the template editor inside your product so a customer changes their own packing list without opening a ticket with you. Your developers integrate once; your customers become their own template team.

A bill of lading, a CMR consignment note, a packing list, a commercial invoice, a delivery note and a pallet label all describe the same consignment. In most transport and warehouse systems each one is its own report, hard-coded by a developer years ago, formatted slightly differently, and updated by ticket.

So the new customs field goes into the commercial invoice and misses the packing list. The customer who wants their logo on the delivery note is told it will be in the next release. The dispatch run prints the labels from one system and the CMRs from another, and the two disagree about the consignee’s postcode.

Every one of those documents is legally or commercially binding once the truck leaves. They should not be the slowest part of your stack to change.

There is no fixed list of document types. A template is whatever you lay out in the editor: a form you already print, a label sized to your stock, a multi-page manifest, a one-line delivery receipt. If you can describe it, the same API generates it from your data, with the same barcodes, conditional content and per-customer branding available in every one. The nine below are the ones logistics teams ask us about most, and every one of them can come from the same shipment payload.

A label that does not scan stops a line. Barcodes and QR codes are rendered inside the document at generation time, as vectors, from the value in your payload. There is no external image service to fail, no resampled PNG to blur, and no size mismatch between the barcode and the label stock.

• Over 30 formats: the Code 128 family including GS1-128, EAN and UPC, Code 39 and 93, ITF, Codabar, postal codes, and on the 2D side QR, Data Matrix, PDF417 and Aztec
• Encode the SSCC, the tracking number or the order reference straight from your WMS field
• QR codes for tracking links, rendered deterministically, so the same input gives the same code every time
• Human-readable text under the bars, scaled to the barcode width

When two hundred consignments leave at 16:00, you do not want two hundred API calls and two hundred PDFs to collate. A batch request takes a list of template and data pairs and returns them merged as one file, ready for the printer. Run it asynchronously and we post the result to your callback URL when it is done, so your dispatch process is not blocked while the documents render.

• POST /documents/generate/batch for one merged file from many documents
• POST /documents/generate/async and /batch/async with a callback_url for long runs
• Mix templates in one batch: the CMR, the packing list and the labels for the same load in one file
• Returned as a URL, base64 or a stored document you fetch later

A 3PL ships on behalf of a hundred brands. A TMS vendor serves a hundred forwarders. Neither wants their own logo on the delivery note the consignee sees. Workspaces solve this: each customer’s templates live in their own workspace, with their own logo, footer, colours and wording, and the API call names the workspace. The same integration, a different document for every customer.

If you build the platform, take it a step further. Embed the template editor inside your product and the forwarder edits their own CMR layout without contacting you. Veeqo, an inventory and shipping platform for retailers, uses this so its customers design their own picking and packing slips, drop notes and address labels.

• One workspace per customer or per brand, scoped with a JWT so a customer only sees their own templates
• White-label output: no PDF Generator API branding on the document
• Embedded editor for platforms, or a shared template set that operations edits for all customers

Most e-signature tools want a finished PDF uploaded to them. Proof of delivery starts a step earlier: generate the document from the shipment data, request output=viewer, and you get a URL that opens it in a review-and-sign flow on the driver’s phone. The consignee confirms their details and signs into their own field. Every signature is sealed with a certificate from a publicly trusted certificate authority and countersigned by an RFC 3161 timestamp authority, so the signed POD opens without a warning in any PDF reader.

For high-volume acknowledgements you can switch off the drawn-signature step at organisation level. The consignee confirms in one tap, the signature is applied automatically, and the audit trail still records who signed, when, and from which IP address.