Compliance and archival

API เรนเดอร์ e-invoice สำหรับระบบ production

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

PRIMARY API E-Invoice Render
ENDPOINT /api/v1/e-invoice/render
SYSTEMS operations backend / finance system / compliance workflow / document service
งานที่ต้องทำให้เสร็จ

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

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

  • Backend มีข้อมูล e-invoice rendering อยู่แล้วและต้องการ 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/e-invoice/render

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

SECONDARY 1

/api/v1/e-invoice/capabilities

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

Minimal request

/api/v1/e-invoice/render - e-invoice rendering

{
  "settings": {
    "profile": "pdfa-3b",
    "e_invoice": {
      "standard": "factur_x",
      "profile": "en16931",
      "document_type": "invoice",
      "xml": {
        "format": "cii",
        "encoding": "utf8",
        "content": "<?xml version=\"1.0\" encoding=\"UTF-8\"?><rsm:CrossIndustryInvoice>...</rsm:CrossIndustryInvoice>"
      }
    }
  },
  "pages": [
    {
      "size": "a4",
      "elements": [
        {
          "type": "text",
          "x": 20,
          "y": 24,
          "content": "Invoice INV-1007",
          "style": { "font_size": 16, "font_family": "NotoSans-Regular" }
        }
      ]
    }
  ]
}

gPdf จัดการอะไร

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

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

  • ข้อมูล e-invoice rendering ที่ถูกต้อง, business rules และ operation state.
  • Authentication, storage, external workflows และ receiver validation.

Production checklist

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

ขอบเขตของ claim

  • gPdf ใช้ public e-invoice endpoint สำหรับ Factur-X / ZUGFeRD PDF/A-3b.
  • Tax portals, PDP, SDI, KSeF, ZATCA, IRP, Peppol และ legal obligations อยู่นอก scope.
  • Buyer data, tax logic, routing และ local legal interpretation อยู่ในระบบของคุณ.

API shape

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

Endpoint choice

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

Validation ก่อน production

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

FAQ

นี่คือ endpoint แยกหรือไม่
API เรนเดอร์ e-invoice ใช้ public e-invoice endpoint สำหรับ Factur-X / ZUGFeRD PDF/A-3b. ไม่ใช่ product surface แยก.
ครอบคลุม local clearance networks หรือไม่
ไม่. gPdf render และ package PDF/e-invoice file; tax portals และ legal routing อยู่ในระบบของคุณ.
ยังใช้ JSON Render ได้ไหม
ได้สำหรับ ordinary PDFs. ใช้ E-Invoice Render เมื่อ output ต้องมี structured e-invoice package.