Archival PDF generation के लिए PDF/A API
Archival workflows के लिए JSON Render requests से PDF/A output generate करें, PDF/A profiles और e-invoice packaging के बीच clear boundary के साथ.
/api/v1/pdf/render Structured document requests से PDF/A-profile output generate करें जब business workflow को archival-friendly PDFs चाहिए, और embedded XML invoice packaging required होने पर ही E-Invoice Render चुनें.
यह API कब इस्तेमाल करें
- आपके workflow को render settings में selected PDF/A profile चाहिए.
- आपको archival invoice, statement, report या document output चाहिए.
- आपको PDF/A-3b e-invoice packaging से broader general PDF/A page चाहिए.
- आप produced file को अपने archival acceptance workflow से validate कर सकते हैं.
यह क्या replace नहीं करता
- आपको embedded EN 16931 CII XML वाला Factur-X या ZUGFeRD चाहिए. E-Invoice Render use करें.
- आपको validator-only workflow चाहिए. Validation context के लिए validator pages use करें.
- आपको same request में encrypted output और PDF/A चाहिए. Public Render API security settings और PDF/A profile settings को mutually exclusive मानती है.
कौन सा endpoint call करें
/api/v1/pdf/render
JSON Render इस workflow का default path है।
/api/v1/e-invoice/render
जब workflow को related API path, template contract या capabilities lookup चाहिए, तब इसका उपयोग करें।
Minimal request
POST /api/v1/pdf/render - ordinary PDF/A output setting.
{
"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 क्या handle करता है
- JSON Render requests पर PDF/A profile settings.
- Text, tables, images, barcodes, metadata और profile output के साथ document rendering.
- PDF/A-3b e-invoice packaging सिर्फ E-Invoice Render path से.
- Shared error behavior के साथ binary PDF response.
आपका system क्या संभालता है
- Archival policy, profile selection, validation workflow, retention और legal acceptance.
- Document semantics, business data और required external evidence.
- Storage, access control और future migration policy.
Production checklist
- अपने archive या customer के लिए required PDF/A profile select करें.
- Output को अपने validator और retention acceptance workflow से pass कराएं.
- जब तक public docs compatible contract न जोड़ें, PDF/A और security settings को separate render flows में रखें.
- Embedded CII XML required हो तो E-Invoice Render use करें.
- Source data या returned PDF को retention policy के हिसाब से store करें.
Claim boundaries
- PDF/A output legal e-invoice packaging जैसा नहीं है.
- gPdf आपके archival acceptance या validator workflow को replace नहीं करता.
- Retention और compliance interpretation आपका system own करता है.
PDF/A एक profile choice है
Ordinary archival documents के लिए PDF/A render settings से select होता है. यह workflow को JSON Render के करीब रखता है: आपका system document describe करता है और required profile set करता है.
E-invoice packaging अलग है. जब document को embedded CII XML के साथ Factur-X या ZUGFeRD चाहिए, तो E-Invoice Render endpoint use करें.
FAQ
- General PDF/A output के लिए कौन सा endpoint use करना चाहिए?
- Ordinary PDF/A output के लिए appropriate settings.profile value के साथ POST /api/v1/pdf/render use करें.
- E-Invoice Render कब चाहिए?
- जब document को embedded CII XML वाला Factur-X या ZUGFeRD PDF/A-3b package होना चाहिए, तब E-Invoice Render use करें.
- क्या gPdf archival acceptance validate करता है?
- नहीं. gPdf PDF/A output render करता है. आपके system को output को archive या customer acceptance policy के against validate करना चाहिए.
- क्या PDF/A को security settings के साथ combine कर सकते हैं?
- Current public Render API में नहीं. settings.profile और settings.security mutually exclusive हैं और invalid combinations validation fail करते हैं.