How invoice-api works
Invoice data in, a compliant e-invoice out – and in the other direction, read and check e-invoices you receive.
The building blocks
Every building block is one endpoint. The status is the same one every other surface shows – planned means planned, and always with a date.
| Building block | What it does | When you need it | Endpoint | Reference |
|---|---|---|---|---|
VeriFactu Declaración (ES)Live | Hands out the software manufacturer's declaración responsable — the document that must be viewable inside the system under art. 13.2 RD 1007/2023. | When the AEAT or an auditor wants to know who is behind the software. | GET /api/v1/verifactu/declaracion | Reference |
VeriFactu Chain Export (ES)Live | Hands out the complete registro chain of one NIF as a single JSON document, each entry next to its huella (art. 14 RD 1007/2023). | When an inspection asks for the records, or you want to recompute the hashes yourself. | GET /api/v1/verifactu/chain/{vatId}/export | Reference |
Invoice CreatorLive | Turns your invoice data into a finished e-invoice in the target country's format. | Whenever you send an invoice – this is the main path. | POST /api/v1/invoice/{countryCode}/{format}/generate | Reference |
PDF EmbedderLive | Places the generated XML into your finished invoice PDF – your layout carries the e-invoice. | When the visual page comes from your ERP or your print shop and has to reach the recipient exactly as it is. | POST /api/v1/invoice/{countryCode}/{format}/embed | Reference |
ValidatorLive | Checks an invoice against the rules of the country (EN 16931, KoSIT, Peppol) and reports every violation with its rule id. | Before you send, and when you decide whether to accept or reject an invoice you received. | POST /api/v1/invoice/{countryCode}/validate | Reference |
ParserLive | Reads a foreign e-invoice – XML or ZUGFeRD PDF – into the same JSON structure the creator accepts. | On inbound invoices, when the fields need to reach your bookkeeping. | POST /api/v1/invoice/parse | Reference |
FormatsLive | Lists which countries and formats are available — per format its code, label and kind (e-invoice or PDF). | When your UI should build the choice itself instead of hard-wiring it. | GET /api/v1/invoice/formats | Reference |
ConverterLive | Converts a finished e-invoice into another format and reports what does not survive the move. | When you hold an XRechnung but your recipient asks for ZUGFeRD – or the other way round. | POST /api/v1/invoice/convert | Reference |
AttachmentsLive | Embeds files into an existing PDF without losing its PDF/A-3 conformance. | When a timesheet, a delivery note or a proof of work should travel with the invoice. | POST /api/v1/invoice/attachments | Reference |
VeriFactu QR (ES)Live | Produces the QR code required by the Spanish VeriFactu rules, as URL, PNG or SVG. | When you invoice into Spain and the document has to carry the QR code. | POST /api/v1/invoice/es/verifactu-qr | Reference |
VisualizerPlanned Q4/2026 | Renders an e-invoice as a view for humans. | When you want to show XML inside your own product without building a layout yourself. | POST /api/v1/invoice/render | Reference |
ArchivePlanned 2027 | Stores invoice and validation report in an audit-proof way. | When you would rather not run the legally required retention yourself. | POST /api/v1/invoice/archive | Reference |
Peppol GatewayPlanned 2027 | Hands the invoice to the Peppol network and takes the delivery receipts back. | When the recipient is addressed via Peppol. Until then: send by e-mail or portal. | POST /api/v1/peppol/send | Reference |
Three typical paths
Almost every integration is one of these three – or a combination of two.
Outbound: send an invoice
- 1Assemble the invoice data from your system as JSON.
- 2Call generate; country and format sit in the path, e.g. DE and xrechnung.
- 3Optional attachments: embed the proof of work or delivery note into the PDF.
- 4Hand the result to the recipient by e-mail or portal.
Inbound: read and check an invoice
- 1Send the file you received – XML or ZUGFeRD PDF – to parse.
- 2validate returns the report with rule ids: the basis for accepting or rejecting.
- 3Take the fields from the response into your bookkeeping.
Convert: change the format
- 1Send the source file, e.g. an XRechnung, to convert.
- 2Choose the target format: zugferd, facturx or xrechnung.
- 3Read conversionWarnings – it names what the target format does not know.
What the service does not do
Three limits worth knowing before you integrate – so nobody goes looking in the wrong place.
No OCR for scanned PDFs
parse reads structured data: XML, or the XML embedded in a ZUGFeRD PDF. A scanned paper PDF contains none, and none is guessed here.
A PDF that carries a text layer — the same Word template every time, say — can be read: in the n8n template the local pdf2invoice node pulls the text and assembles the invoice from a rule set, with no OCR and no AI. That node is not published on npm yet — the template names the install path.
n8n template: PDF to e-invoiceNo Peppol dispatch
Peppol access is planned for 2027. Until then the file is produced here; the transport is yours or your access point's.
Attaching a file does not make an e-invoice
attachments embeds files into a PDF, nothing more – it does not produce the embedded XML of an e-invoice. If your own PDF should become the visual page of a ZUGFeRD invoice, embed is the way: we generate the XML from your data and place it into your PDF. PDF/A-3 is declared on your carrier, not converted.
Attachments API