क्या PDF/A-3b हमेशा e-invoice होता है?

नहीं. PDF/A-3b archival PDF profile है. Factur-X और ZUGFeRD e-invoices embedded EN 16931 XML के wrapper के रूप में PDF/A-3b use करते हैं.

कौन सा endpoint PDF/A-3b बनाता है?

Ordinary PDF/A-3b के लिए settings.profile के साथ POST /api/v1/pdf/render use करें. Output को Factur-X या ZUGFeRD e-invoice होना हो तो POST /api/v1/e-invoice/render use करें.

क्या मैं इस page से arbitrary files attach कर सकता हूँ?

Public API docs उस workflow को list न करें तो arbitrary attachment support assume न करें. यह page documented PDF/A-3b और e-invoice use पर focus करता है.

PDF/A output verify कैसे करूँ?

/validator/ या अपना reference-engine pipeline use करें. E-invoices के लिए PDF/A layer और embedded XML layer दोनों validate करें.

Compliance और archival

Archival और e-invoice workflows के लिए PDF/A-3b API

gPdf से PDF/A-3b output generate करें और समझें कि PDF/A-3b कब सिर्फ archival profile है और कब e-invoice wrapper.

PRIMARY API JSON Render

ENDPOINT /api/v1/pdf/render

SYSTEMS compliance backend / finance system / legal archive / audit workflow

Playground में आज़माएँ Docs पढ़ें

काम जो पूरा करना है

Archival workflows के लिए PDF/A-3b documents generate करें और e-invoice endpoint तब चुनें जब PDF/A-3b को embedded Factur-X या ZUGFeRD EN 16931 XML carry करना हो.

यह API कब इस्तेमाल करें

Rendered document के लिए PDF/A-3b archival profile चाहिए.
Ordinary PDF/A और e-invoice packaging के बीच boundary explain करनी है.
आपका compliance workflow generated PDFs को veraPDF या किसी reference engine से validate करता है.
PDF/A-3b search intent को correct endpoint तक route करने के लिए public page चाहिए.

यह क्या replace नहीं करता

आपको public API में documented नहीं arbitrary file-attachment workflows चाहिए.
आप JSON Render से Factur-X या ZUGFeRD e-invoices चाहते हैं. E-Invoice Render use करें.
आपको validator API चाहिए. Current public validator surface /validator/ page है.

कौन सा endpoint call करें

PRIMARY

/api/v1/pdf/render

JSON Render इस workflow का default path है।

SECONDARY 1

/api/v1/e-invoice/render

जब workflow को related API path, template contract या capabilities lookup चाहिए, तब इसका उपयोग करें।

Minimal request

POST /api/v1/pdf/render - rendered document के लिए PDF/A-3b output request.

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

gPdf क्या handle करता है

JSON Render settings से PDF/A profile selection.
POST /api/v1/e-invoice/render use करते समय PDF/A-3b e-invoice packaging.
External reference-engine validation के लिए suitable renderable PDF output.
Archival profile और legal e-invoice workflow के बीच clear separation.

आपका system क्या संभालता है

Retention policy और PDF/A-3b required होने का reason.
Business data, XML semantics और external compliance acceptance criteria.
Validation evidence, audit records और rendering के बाद long-term storage.

Production checklist

Ordinary PDF/A-3b output के लिए JSON Render चुनें.
Embedded EN 16931 XML required हो तो E-Invoice Render चुनें.
PDF/A output को /validator/ या अपने veraPDF workflow से validate करें.
Stored document के साथ requested profile और request ID record करें.
जब तक public docs list न करें, arbitrary attachments support claim न करें.

Claim boundaries

PDF/A-3b archival profile है; e-invoice packaging उसके ऊपर narrower workflow है.
हर arbitrary embedded-file workflow supported है, ऐसा imply न करें.
Factur-X और ZUGFeRD PDF/A-3b packages के लिए e-invoice route required है.

PDF/A-3b wrapper है, पूरा workflow नहीं

PDF/A-3b एक PDF archival profile है. यह इसलिए matter करता है क्योंकि hybrid e-invoices के लिए wrapper बन सकता है, लेकिन profile alone किसी document को legal e-invoice नहीं बनाती. Ordinary archived document embedded invoice XML के बिना भी PDF/A-3b use कर सकता है.

Factur-X और ZUGFeRD के लिए POST /api/v1/e-invoice/render use करें. वह endpoint e-invoice-specific metadata और associated-file wiring के लिए responsible है.

Intent के हिसाब से endpoint चुनें

जब आपका goal “इस document को PDF/A-3b के रूप में render करना” हो, तब JSON Render use करें. जब goal “इस invoice को EN 16931 CII XML के साथ Factur-X या ZUGFeRD के रूप में package करना” हो, तब E-Invoice Render use करें. यह distinction code को clear रखता है और ordinary archival jobs में accidental e-invoice assumptions से बचाता है.

Externally validate करें

PDF/A को marketing claim से नहीं, reference engine से verify करना चाहिए. Public validator या अपना validation pipeline use करें और report को audit evidence के साथ store करें.

FAQ

क्या PDF/A-3b हमेशा e-invoice होता है?: नहीं. PDF/A-3b archival PDF profile है. Factur-X और ZUGFeRD e-invoices embedded EN 16931 XML के wrapper के रूप में PDF/A-3b use करते हैं.
कौन सा endpoint PDF/A-3b बनाता है?: Ordinary PDF/A-3b के लिए settings.profile के साथ POST /api/v1/pdf/render use करें. Output को Factur-X या ZUGFeRD e-invoice होना हो तो POST /api/v1/e-invoice/render use करें.
क्या मैं इस page से arbitrary files attach कर सकता हूँ?: Public API docs उस workflow को list न करें तो arbitrary attachment support assume न करें. यह page documented PDF/A-3b और e-invoice use पर focus करता है.
PDF/A output verify कैसे करूँ?: /validator/ या अपना reference-engine pipeline use करें. E-invoices के लिए PDF/A layer और embedded XML layer दोनों validate करें.