Логістика та етикетки

API транспортних етикеток для PDF-етикеток 4x6

Генеруйте готові до друку PDF транспортних етикеток 4x6 із JSON замовлення, векторними штрихкодами, розмірами сторінок етикеток і детермінованими складськими передруками.

ОСНОВНА API JSON Render
ШЛЯХ API /api/v1/pdf/render
СИСТЕМИ WMS / OMS / 3PL-бекенд / бекенд доставки
Задача сценарію

Рендерити PDF розміру етикетки з даних замовлення, отримувача, сервісу й трекінгу, щоб складський або бекенд електронної комерції міг надійно друкувати ту саму етикетку 4x6 під час виконання замовлення й детерміновано передруковувати її за потреби.

Коли використовувати цю API

  • У вашій системі вже є номер трекінгу, адреса призначення, службовий текст і дані штрихкоду.
  • Потрібен PDF-вивід для Zebra, SATO, Honeywell або інших процесів із термопринтерами.
  • Потрібні векторні модулі штрихкоду замість растрових зображень штрихкоду, вставлених у PDF.
  • Потрібно, щоб ті самі дані рендерили ту саму етикетку для передруку й аудиторських доказів.

Що вона не замінює

  • Потрібно купити поштові послуги, розрахувати тариф відправлення або створити етикетку перевізника через акаунт перевізника.
  • Потрібен маршрут-замінник ZPL. gPdf повертає PDF, а не мову команд принтера.
  • Потрібна сертифікація перевізника від gPdf. Тестування сканування й прийняття перевізником залишаються вашою відповідальністю.

Який шлях API викликати

ОСНОВНИЙ

/api/v1/pdf/render

JSON Render — типовий шлях для цього сценарію.

ДОДАТКОВИЙ 1

/api/v1/template-render

Використовуйте, коли сценарію потрібен пов’язаний API-шлях, контракт шаблону або перевірка можливостей.

Мінімальний запит

POST /api/v1/pdf/render - мінімальна етикетка 4x6 зі штрихкодом трекінгу.

{
  "pages": [
    {
      "size": "label_4_6_in",
      "elements": [
        {
          "type": "text",
          "x": 4,
          "y": 6,
          "content": "SHIP TO",
          "style": { "font_size": 8, "font_family": "NotoSans-Regular" }
        },
        {
          "type": "text",
          "x": 4,
          "y": 13,
          "content": "Acme Warehouse\n1200 Logistics Pkwy\nMemphis TN 38116",
          "style": { "font_size": 11, "font_family": "NotoSans-Regular" }
        },
        {
          "type": "barcode",
          "format": "code128",
          "content": "1Z999AA10123456784",
          "x": 4,
          "y": 62,
          "width": 92,
          "height": 22,
          "barcode_text": { "enabled": true, "position": "bottom" }
        }
      ]
    }
  ]
}

Що виконує gPdf

  • PDF-сторінки розміру етикетки, зокрема процеси 4x6 inch.
  • Рендеринг векторних штрихкодів для вмісту етикеток перевізника й складу.
  • Текст, адресні блоки, службові позначки, лінії, рамки й необов’язкову прив’язку шаблону.
  • Детермінований PDF-вивід для складських передруків.

Що контролює ваша система

  • Акаунт перевізника, купівлю поштових послуг, вибір сервісу й створення номера трекінгу.
  • Коректні дані штрихкодів, читабельний текст, адреси й дані маршрутизації.
  • Налаштування принтера, матеріал етикеток, тестування сканування й перевірки прийняття перевізником.

Чеклист для робочого запуску

  1. Друкуйте тестові етикетки на реальній моделі принтера й реальному матеріалі етикеток.
  2. Перевіряйте успішність сканування штрихкоду на цільовому DPI й відстані сканера.
  3. Зберігайте вихідні дані відправлення або повернений PDF відповідно до політики передруку.
  4. Використовуйте Template Render після затвердження макета етикетки й повторного використання в системах.
  5. Тримайте логіку конкретного перевізника поза запитом рендерингу.

Межі заявлених можливостей

  • gPdf рендерить PDF етикетки; він не купує поштові послуги і не звертається напряму до перевізників.
  • gPdf не є органом сертифікації етикеток перевізника.
  • API повертає PDF, а не ZPL, EPL або інший потік команд термопринтера.

Форма API транспортних етикеток

Сторінки транспортних етикеток не є окремим маршрутом перевізника. Ви викликаєте JSON Render зі сторінкою розміру етикетки, текстовими блоками, лініями, необов’язковими зображеннями й елементами штрихкоду. Для повторюваних етикеток опублікуйте затверджений макет як шаблон і викликайте Template Render із дані відправлення.

Так межа відповідальності лишається чіткою. gPdf відповідає за PDF-рендеринг і малювання штрихкодів. Ваша система відповідає за транзакцію з перевізником, стан відправлення і семантику даних.

JSON Render проти Template Render

Використовуйте JSON Render, коли система виконання замовлень генерує весь макет або коли операційна команда ще налаштовує координати. Використовуйте Template Render, коли склад затвердив стабільний макет етикетки й кожен сервіс-викликач має надсилати ті самі поля даних.

Обидва шляхи повертають PDF. Різниця в тому, чи сервіс-викликач описує макет у кожному запиті, чи посилається на опублікований template_id.

Друкарське тестування важливе

Якість термоетикетки фізична. Перевіряйте вивід на реальному матеріалі етикеток, реальних принтерах і реальних сканерах. Коректність даних штрихкоду, quiet zones, темність друку й правила конкретного перевізника — бойова відповідальність поза render API.

FAQ

Чи створює gPdf етикетки перевізника за мене?
Ні. Ваш перевізник або shipping-система створює відправлення перевізника й дані штрихкоду. gPdf рендерить ці дані в PDF-етикетку.
Чи можна використовувати Template Render для транспортних етикеток?
Так. Використовуйте JSON Render під час проєктування або тестування етикетки, а потім Template Render, коли макет стабільний і сервіси-викликачі мають надсилати лише дані.
Чи виводить gPdf ZPL?
Ні. Публічні render API повертають PDF. Якщо ваш друкарський шлях потребує ZPL, конвертуйте або маршрутизуйте PDF поза gPdf.
Що перевірити перед бойовим запуском?
Друкуйте на реальному принтері й матеріалі етикеток, скануйте штрихкод бойовими сканерами та підтверджуйте, що специфічний для перевізника текст і дані надходять із вашої shipping-системи.