Logistics and labels
倉庫・3PL 向けパレットラベル API
パレットラベル API: ブラウザレンダリングなしでパレット識別子とルーティング情報を堅牢な PDF ラベルにする。gPdf の描画責任と自社の業務データ責任を明確に分けます。
主 API JSON Render
ENDPOINT
/api/v1/pdf/render 対象システム WMS / 3PL バックエンド / ERP エクスポートサービス / 倉庫印刷サービス
解決する業務課題
パレット識別子とルーティング情報を堅牢な PDF ラベルにする。自社システムが業務データとルールを持ち、gPdf はそれを PDF として再現性高く出力します。
この API が合う場合
- 自社システムがパレットラベルに必要なデータをすでに持っており、PDF レスポンスが必要です。
- ブラウザベースの HTML to PDF ではなく、/api/v1/pdf/render の JSON Render を使いたい場合。
- レイアウト、バーコード、テキスト、メタデータを構造化データから再現可能に生成したい場合。
- 本番投入前に Playground や CI でペイロードを再現検証したい場合。
置き換えないもの
- 配送キャリア契約、運賃購入、ルーティング判断、スキャナー認証を gPdf に任せたい場合。
- ZPL/EPL の代替を探している場合。gPdf の出力は PDF です。
- 業務コードやマスターデータをレンダラー側で生成したい場合。
呼び出す endpoint
/api/v1/pdf/render
JSON Render がこのワークフローの標準パスです。
/api/v1/template-render
関連 API パス、テンプレート契約、または機能確認が必要な場合に使います。
最小リクエスト
/api/v1/pdf/render - パレットラベルの最小リクエスト。
{
"pages": [
{
"size": "label_4_6_in",
"elements": [
{
"type": "text",
"x": 5,
"y": 7,
"content": "PALLET 12 / DOCK B",
"style": { "font_size": 13, "font_family": "NotoSans-Regular" }
},
{
"type": "barcode",
"format": "sscc-18",
"content": "000123456789012345",
"x": 5,
"y": 28,
"width": 92,
"height": 30,
"barcode_text": { "enabled": true, "position": "bottom" }
},
{
"type": "text",
"x": 5,
"y": 78,
"content": "GTIN 09506000134352\nQTY 48 CASES\nLOT L-2026-05",
"style": { "font_size": 10, "font_family": "NotoSans-Regular" }
}
]
}
]
}
gPdf が担当すること
- 構造化リクエストからパレットラベルをレンダリングします。
- 必要に応じて PDF ページ、テキスト、表、線、図形、画像、ベクターバーコードを描画します。
- 再印刷、監査、バックエンド自動化に向いた再現性のある PDF を返します。
- 失敗時は API-XXX コードと req_id を含む共通エラー形式を返します。
自社システムが担当すること
- 業務データ、フィールドマッピング、文書の意味付け。
- レスポンス後の検証、冪等性、ファイル名、保存、追跡。
- プリンター、用紙、読み取り品質、倉庫または配送現場での運用承認。
本番前チェックリスト
- 本番呼び出しには request ID と timeout を設定します。
- OpenAPI、ドキュメント、Golden PDF テストでペイロードを検証します。
- API ベース URL と bearer token は設定化し、ソースコードに埋め込みません。
- 重要レイアウトは実データと境界ケースでテストします。
- 検証証跡と再出力に必要な情報を自社システム側に保持します。
対応範囲の境界
- gPdf はパレットラベルをレンダリングしますが、業務上の正しさは自社システムの責任です。
- このページは適切な gPdf API パスを示すもので、追加のワークフロー専用 endpoint ではありません。
- 外部認証、受け入れ判定、現場の運用承認はレンダラーの範囲外です。
このワークフローと gPdf の関係
パレットラベル API は、公開 gPdf API を使う本番向けワークフローです。リクエストでは、データ、レイアウト、settings、PDF に描画する要素を明示します。gPdf が担当するのはレンダリングであり、データの業務判断ではありません。
API パスと責任境界
多くの場合、/api/v1/pdf/render の JSON Render が出発点になります。マスターデータ、検証、保存、業務ルールは自社システム側に残ります。つまり、gPdf は PDF を生成し、アプリケーションが意味とプロセスを制御します。
本番化の確認
パレットラベルは、ワークフローに応じて実データ、プリンター、スキャナー、検証エンジン、受信側システムで確認してください。サポート、監査、再出力に使えるよう request ID と検証証跡を保存します。
FAQ
- パレットラベル API は専用 endpoint ですか？
- いいえ。このページは /api/v1/pdf/render と関連する gPdf API をこのワークフローでどう使うかを説明します。
- 自社システムは何を用意しますか？
- 業務データ、フィールドマッピング、検証、本番ルールは自社システムが用意します。gPdf は PDF 生成を担当します。
- Template Render はいつ使いますか？
- レイアウトが固定され、呼び出し側が template_id と data[] だけを送ればよい段階で Template Render を使います。
- 本番前に何を確認しますか？
- 実データ、境界ケース、検証、PDF を読む・印刷する・保管する後続システムで確認します。