PDF/A API для архівного створення PDF
Генеруйте PDF/A-вивід із запитів JSON Render для архівних процесів із чіткою межею між PDF/A profiles і пакуванням електронного рахунку.
/api/v1/pdf/render Генерувати вивід із PDF/A profile зі структурованих запитів документа, коли бізнес-процесу потрібні архівно дружні PDF, і обирати E-Invoice Render лише тоді, коли потрібне пакування рахунку з вбудованим XML.
Коли використовувати цю API
- Вашому процесу потрібен PDF/A profile, вибраний у render settings.
- Потрібен архівний вивід рахунку, виписки, звіту або документа.
- Потрібна загальна сторінка PDF/A, ширша за пакування PDF/A-3b електронного рахунку.
- Ви можете валідувати створений файл власним процесом архівного прийняття.
Що вона не замінює
- Потрібен Factur-X або ZUGFeRD із вбудованим EN 16931 CII XML. Використовуйте E-Invoice Render.
- Потрібен лише процес валідації. Для контексту валідації використовуйте сторінки validator.
- Потрібні зашифрований вивід і PDF/A в одному запиті. Публічний Render API розглядає security settings і PDF/A profile settings як взаємовиключні.
Який шлях API викликати
/api/v1/pdf/render
JSON Render — типовий шлях для цього сценарію.
/api/v1/e-invoice/render
Використовуйте, коли сценарію потрібен пов’язаний API-шлях, контракт шаблону або перевірка можливостей.
Мінімальний запит
POST /api/v1/pdf/render - звичайне налаштування PDF/A-виводу.
{
"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/A profile у запитах JSON Render.
- Рендеринг документа з текстом, таблицями, зображеннями, штрихкодами, метаданими й profile output.
- Пакування PDF/A-3b електронного рахунку лише через шлях E-Invoice Render.
- Бінарну PDF-відповідь зі спільною поведінкою помилок.
Що контролює ваша система
- Архівну політику, вибір profile, процес валідації, retention і юридичне прийняття.
- Семантику документа, бізнес-дані й будь-які потрібні зовнішні докази.
- Зберігання, контроль доступу й політику майбутньої міграції.
Чеклист для робочого запуску
- Оберіть PDF/A profile, потрібний вашому архіву або клієнту.
- Пропустіть вивід через ваш validator і процес прийняття за політикою retention.
- Тримайте PDF/A і security settings в окремих render flows, доки публічна документація не додасть сумісний контракт.
- Використовуйте E-Invoice Render, коли потрібен вбудований CII XML.
- Зберігайте вихідні дані або повернений PDF відповідно до retention policy.
Межі заявлених можливостей
- PDF/A-вивід — не те саме, що юридичне пакування електронного рахунку.
- gPdf не замінює ваш процес архівного прийняття або валідації.
- Ваша система відповідає за retention і тлумачення відповідності.
PDF/A — це вибір профілю
Для звичайних архівних документів PDF/A обирається через render settings. Це тримає процес близько до JSON Render: ваша система описує документ і задає потрібний profile.
Пакування електронного рахунку відрізняється. Коли документу потрібен Factur-X або ZUGFeRD із вбудованим CII XML, використовуйте маршрут API E-Invoice Render.
FAQ
- Який маршрут API використовувати для загального PDF/A-виводу?
- Використовуйте POST /api/v1/pdf/render з відповідним значенням settings.profile для звичайного PDF/A-виводу.
- Коли потрібен E-Invoice Render?
- Використовуйте E-Invoice Render, коли документ має бути пакетом Factur-X або ZUGFeRD PDF/A-3b із вбудованим CII XML.
- Чи валідує gPdf archival acceptance?
- Ні. gPdf рендерить PDF/A-вивід. Ваша система має валідувати результат за політикою прийняття архіву або клієнта.
- Чи можна поєднати PDF/A із security settings?
- Не в поточному публічному Render API. settings.profile і settings.security взаємовиключні; недійсні комбінації не проходять валідацію.