Order raised or shipment leaves → the paperwork with it
The warehouse cannot wait for someone to open a spreadsheet.
Trigger → artefact
An order is approved, or a shipment is dispatcheda purchase order, a quotation or a packing slip, as PDF bytes
Operational documents are boring and unforgiving. A packing slip with the wrong quantity is a return; a purchase order without terms is an argument later. They also have to exist the second the event happens, which rules out anything a human has to touch.
One call, one document, same shape as the rest of the API. The purchase order template also produces quotations — the same document with a different heading and a validity date — so one integration covers both.
Run against the API before publishing: 200, application/pdf. Set document_kind to “quotation” on the purchase order template and the same call returns a quote.
The contract
Exactly what you send, exactly what you get.
These templates take named keys — no positional arguments, no layout to describe. Send a row array and the pagination follows it.
Send as many as you have. Pagination, running totals and the carried-forward header are the renderer's problem, not yours.
What you would ask next.
We need a barcode on the packing slip.
Not today. You can place an image you host, so a barcode you already generate will render — but we do not generate the barcode itself. If that blocks you, say so and it moves up.
Can it print on our pre-printed stationery?
Yes — page size and margins are yours to set, and the PDF is pure vector, so it prints at whatever the printer can do rather than at a raster resolution we chose.
Our ERP sends XML, not JSON.
Then something in the middle has to translate, and it is not us. We take JSON over HTTPS; that is the whole interface.
Your system already knows when the document is owed.