e-faktur: API dla produkcji
Generowanie e-faktur ze strukturalnych danych backendu, bez przeglądarki, z jasną granicą między gPdf renderingiem a regułami Twojego systemu.
/api/v1/e-invoice/render Generowanie e-faktur jako powtarzalnego PDF ze strukturalnych danych. gPdf tworzy dokument; Twój system odpowiada za znaczenie danych i stan procesu.
Kiedy użyć tej API
- Backend ma już dane dla e-faktur i potrzebuje stabilnej odpowiedzi PDF.
- Chcesz uniknąć Chromium lub HTML-to-PDF w dokumencie operacyjnym.
- Potrzebujesz powtarzalnego wyniku do reprintów, audytu lub batchy.
Czego nie zastępuje
- gPdf nie kupuje wysyłki, nie rozlicza podatków, nie tworzy zewnętrznych zamówień i nie jest systemem fiskalnym.
- gPdf nie zastępuje reguł biznesowych, walidacji danych ani integracji marketplace.
Który endpoint wywołać
/api/v1/e-invoice/render
E-Invoice Render to domyślna ścieżka dla tego workflow.
/api/v1/e-invoice/capabilities
Użyj, gdy workflow potrzebuje powiązanej API, kontraktu szablonu albo sprawdzenia capabilities.
Minimalny request
/api/v1/e-invoice/render - e-faktur
{
"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" }
}
]
}
]
}
Co obsługuje gPdf
- Rendering PDF dla e-faktur ze strukturalnego requestu.
- Tekst, tabele, linie, kody kreskowe, strony, metadane i opcje wyjścia zgodnie z requestem.
- Deterministyczny output dla retry, reprintów i audytu.
Co kontroluje Twój system
- Poprawne dane dla e-faktur, reguły biznesowe i stan operacji.
- Autentykacja, przechowywanie, zewnętrzne workflow i walidacja u odbiorcy.
Checklist produkcyjny
- Testuj na prawdziwych danych i w systemach, które odbiorą PDF.
- Zachowuj request ID i dowody walidacji dla supportu, audytu i reprintów.
- Zamień zaakceptowany layout w template, gdy ma być współdzielony.
Granice deklaracji
- gPdf używa publicznego e-invoice endpoint dla Factur-X / ZUGFeRD PDF/A-3b.
- Portale podatkowe, PDP, SDI, KSeF, ZATCA, IRP, Peppol i obowiązki prawne są poza scope.
- Twój system odpowiada za buyer data, podatki, routing i lokalną ocenę prawną.
Kształt API
API: e-faktur to production workflow oparty na publicznych API gPdf. Request opisuje dane, layout, settings i części PDF do renderingu. gPdf tworzy PDF, a Twój system zachowuje semantykę zdarzenia biznesowego.
Wybór endpointu
Domyślny endpoint dla tego workflow to /api/v1/e-invoice/render. Template Render stosuj po zatwierdzeniu layoutu. E-Invoice Render tylko dla Factur-X / ZUGFeRD PDF/A-3b z osadzonym EN 16931 CII XML.
Walidacja przed produkcją
Waliduj e-faktur na realnych danych i downstream-systemach. Zachowuj request ID, output i dowody walidacji dla supportu, audytu oraz reprintów.
FAQ
- Czy to osobny endpoint?
- API: e-faktur używa publicznego e-invoice endpoint, gdy potrzebny jest Factur-X / ZUGFeRD PDF/A-3b. To nie jest osobna powierzchnia produktu.
- Czy obejmuje lokalne sieci clearance?
- Nie. gPdf renderuje i pakuje PDF/e-invoice; portale podatkowe i routing prawny pozostają w Twoim systemie.
- Czy mogę dalej używać JSON Render?
- Tak dla zwykłych PDF. E-Invoice Render wybierz tylko dla strukturalnego pakietu e-invoice z publicznej API.