QR codes and printable cards

The QR code and the card are not stored ahead of time — each request renders the asset from the container’s current recording URL. That is why both calls take only the container id: there is nothing else to configure.

• The QR code is a PNG image, sized for print or for embedding in another layout.
• The card is a PDF that lays out the same QR code next to text translated into the container’s language.

Requires the containers:qrcode scope. The response body is the PNG image itself, not a JSON wrapper.

curl https://client-api.v5.livstick.com/api/v3/containers/{crid}/qrcode \
  -H "Authorization: Bearer {ACCESS_TOKEN}" \
  -o qrcode.png

Requires the containers:card scope. The response body is the PDF file, ready to send to a print queue or attach to a shipping label.

curl https://client-api.v5.livstick.com/api/v3/containers/{crid}/card \
  -H "Authorization: Bearer {ACCESS_TOKEN}" \
  -o card.pdf

Whichever way it is requested, the QR code always encodes the recipient’s reading URL — never a preview link, and never the sender’s rewrite link. Scanning it takes the recipient straight to the message, every time.

Client API 2.1 exposes the same asset under a differently shaped call: it accepts both GET and POST, and takes the QR code’s colors as query parameters instead of a fixed style. {API_BASE} below is a placeholder — the 2.1 base URL is provided with your access, not published here.

curl "{API_BASE}/v2.1/client/{key}/{crid}/qrcode?dark=000000&light=ffffff"

Generate the QR code or the card once the container is in the state you intend to ship — after you know the recipient’s language, if the card matters, since its text is translated. The QR code’s content does not change afterward: it is tied to the container’s reading URL, not to a snapshot taken at generation time, so a printed card keeps working even if you request the asset again later.