นี่คือ endpoint แยกหรือไม่

API เอาต์พุต PDF/A map workflow ไปยัง public gPdf API path. หน้านี้บอก path ที่ต้อง call และสิ่งที่ request ต้องรับผิดชอบ.

ใช้ templates ได้ไหม

ได้. ใช้ JSON Render เมื่อ layout ยังเปลี่ยนอยู่ และใช้ Template Render เมื่อ layout approve แล้วและ callers ส่งเฉพาะ business data.

ก่อน production ต้อง validate อะไร

Validate ด้วย real data และ printer, scanner, validator, accounting system หรือ marketplace receiver ตาม workflow.

Compliance and archival

API เอาต์พุต PDF/A สำหรับระบบ production

สร้าง PDF/A output จาก structured backend data โดยไม่ใช้ browser. gPdf ทำ PDF rendering และระบบของคุณดูแล business rules.

PRIMARY API JSON Render

ENDPOINT /api/v1/pdf/render

SYSTEMS operations backend / finance system / compliance workflow / document service

ลองใน Playground → อ่านเอกสาร

งานที่ต้องทำให้เสร็จ

สร้าง PDF/A output เป็น PDF ที่ทำซ้ำได้จาก structured data. gPdf render document ส่วน data semantics และ workflow state อยู่ในระบบของคุณ.

ควรใช้ API นี้เมื่อใด

Backend มีข้อมูล PDF/A output อยู่แล้วและต้องการ PDF response ที่เสถียร.
ต้องการหลีกเลี่ยง Chromium หรือ HTML-to-PDF สำหรับ operational document.
ต้องการ output ที่ repeat ได้สำหรับ reprint, audit หรือ batch.

สิ่งที่ไม่ได้ทดแทน

gPdf ไม่ซื้อค่าส่ง ไม่ยื่นภาษี ไม่สร้าง order ภายนอก และไม่ใช่ fiscal system.
ไม่แทนที่ data validation, business rules หรือ marketplace integrations.

ควรเรียก endpoint ใด

PRIMARY

/api/v1/pdf/render

JSON Render คือ path หลักสำหรับ workflow นี้.

SECONDARY 1

/api/v1/e-invoice/render

ใช้เมื่อ workflow ต้องการ API path ที่เกี่ยวข้อง template contract หรือ capabilities lookup.

Minimal request

/api/v1/pdf/render - PDF/A output

{
  "settings": {
    "profile": "pdfa-2b"
  },
  "pages": [
    {
      "size": "a4",
      "elements": [
        {
          "type": "text",
          "x": 20,
          "y": 24,
          "content": "Archive-ready document",
          "style": { "font_size": 16, "font_family": "NotoSans-Regular" }
        }
      ]
    }
  ]
}

gPdf จัดการอะไร

PDF rendering ของ PDF/A output จาก structured request.
Text, tables, lines, barcodes, pages, metadata และ output options ตาม request.
Deterministic output สำหรับ retry, reprint และ audit.

ระบบของคุณรับผิดชอบอะไร

ข้อมูล PDF/A output ที่ถูกต้อง, business rules และ operation state.
Authentication, storage, external workflows และ receiver validation.

Production checklist

ทดสอบด้วย real data และ systems ที่จะ consume PDF.
เก็บ request IDs และ validation evidence สำหรับ support, audit และ reprint.
เปลี่ยน approved layout เป็น template เมื่อหลาย systems ต้อง reuse.

ขอบเขตของ claim

gPdf render PDF จาก request แต่ไม่แทน product workflow, database หรือ business validation.
Data semantics, retries, storage และ final acceptance อยู่ในระบบของคุณ.

API shape

API เอาต์พุต PDF/A คือ production workflow บน public gPdf APIs. Request ระบุ data, layout, settings และ PDF parts ที่ต้อง render. gPdf สร้าง PDF ส่วนความหมายของ business event อยู่ในระบบของคุณ.

Endpoint choice

Default endpoint ของ workflow นี้คือ /api/v1/pdf/render. ใช้ Template Render เมื่อ layout approve แล้วและ reuse หลายระบบ. ใช้ E-Invoice Render เฉพาะเมื่อจำเป็นต้องมี Factur-X / ZUGFeRD PDF/A-3b packaging พร้อม EN 16931 CII XML embedded.

Validation ก่อน production

Validate PDF/A output ด้วย real data และ downstream systems. เก็บ request IDs, rendered output และ validation evidence สำหรับ support, audit และ reprint.

FAQ

นี่คือ endpoint แยกหรือไม่: API เอาต์พุต PDF/A map workflow ไปยัง public gPdf API path. หน้านี้บอก path ที่ต้อง call และสิ่งที่ request ต้องรับผิดชอบ.
ใช้ templates ได้ไหม: ได้. ใช้ JSON Render เมื่อ layout ยังเปลี่ยนอยู่ และใช้ Template Render เมื่อ layout approve แล้วและ callers ส่งเฉพาะ business data.
ก่อน production ต้อง validate อะไร: Validate ด้วย real data และ printer, scanner, validator, accounting system หรือ marketplace receiver ตาม workflow.