Barcodes and retail

PDF417 barcode API for PDF documents and labels

Render PDF417 barcodes in PDFs for logistics, ticket, boarding-pass-style, and document workflows while your system owns the payload rules.

PRIMARY API JSON Render
ENDPOINT /api/v1/pdf/render
SYSTEMS logistics backend / ticketing backend / travel workflow / document automation service
Job to be done

Render PDF417 barcode payloads as vector PDF elements inside labels, tickets, forms, or boarding-pass-style documents while your system owns the encoded format and downstream validation.

When to use this API

  • You need a PDF417 barcode embedded in a PDF document or label.
  • Your system has the final encoded payload and knows the downstream scanner requirements.
  • You need repeated PDF417 layouts through Template Render.
  • You want PDF output rather than a standalone barcode image.

What it does not replace

  • You need gPdf to certify airline, government, logistics, or industry payload formats.
  • You need ticket inventory, seat assignment, or travel booking logic.
  • You need scanner hardware management.

Which endpoint to call

PRIMARY

/api/v1/pdf/render

JSON Render is the default path for this workflow.

SECONDARY 1

/api/v1/template-render

Use this when the workflow needs the related API path, template contract, or capabilities lookup.

Minimal request

POST /api/v1/pdf/render - PDF417 barcode on a ticket-style page.

{
  "pages": [
    {
      "size": "a6",
      "elements": [
        {
          "type": "text",
          "x": 10,
          "y": 14,
          "content": "Boarding pass sample",
          "style": { "font_size": 14, "font_family": "NotoSans-Regular" }
        },
        {
          "type": "barcode",
          "format": "pdf417",
          "content": "M1DOE/JOHN         EABC123 JFKLAX GP 042 001A0001 100",
          "x": 10,
          "y": 38,
          "width": 80,
          "height": 28
        }
      ]
    }
  ]
}

What gPdf handles

  • Vector PDF417 barcode rendering inside PDF output.
  • Document or label layout around the barcode.
  • Template binding for repeated ticket or logistics layouts.
  • Binary PDF response through the public render APIs.

What your system owns

  • Encoded PDF417 payload, industry rules, ticket or shipment state, and customer identity.
  • Scanner acceptance, physical print testing, and fraud prevention.
  • Any downstream booking, access, or logistics operation triggered by the barcode.

Production checklist

  1. Validate the PDF417 payload with the consuming scanner or partner system.
  2. Print and scan at production size and material.
  3. Keep sensitive data out of the barcode unless the destination workflow requires it.
  4. Use Template Render for approved repeated layouts.
  5. Log request IDs with the ticket, shipment, or document ID.

Claim boundaries

  • gPdf renders PDF417 barcodes; it does not certify industry payload formats.
  • Ticketing, travel, identity, and logistics semantics remain yours.
  • Physical scan validation is still required.

PDF417 is the barcode, not the business process

PDF417 often appears in ticket, travel, identity, and logistics workflows. gPdf can render the barcode in a PDF. The payload format, identity checks, booking state, and downstream acceptance remain outside the render API.

FAQ

Does gPdf support PDF417?
Yes. The public barcode format enum includes pdf417 and MicroPDF417 aliases.
Can gPdf create airline boarding pass payloads?
No. gPdf renders the PDF417 value you send. Your travel or ticketing system owns payload construction.
Can PDF417 be used with Template Render?
Yes. Use Template Render when a repeated layout should accept only payload and business data.
Do I need to scan-test the result?
Yes. PDF417 workflows should be validated with the consuming scanners and production print material.