Invoice XML Rendering API Reference

Upload any supported invoice XML and receive a clean, professionally formatted PDF preview. The syntax is detected from the root namespace, so UN/CEFACT CII, UBL Invoice, and UBL CreditNote documents all go to the same route, and XRechnung is covered in either of its syntax bindings. This is the endpoint to reach for when your pipeline handles more than one format: you never have to inspect the file or pick a route before calling. The rendered PDF is for human readability only, it carries no legal standing.

POST https://api.invoicexml.com/v1/render/xml/to/pdf

One route for every supported syntax. This endpoint accepts any type of XML invoice, auto-detects the standard/syntax and renders the PDF preview. Please note that XML invoices may contain attachments in itself. Please refer to the /v1/extract/attachments to extract them as a ZIP archive.

Code Example

curl -X POST https://api.invoicexml.com/v1/render/xml/to/pdf \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -F "[email protected]" \
  -F "language=en"

Request

Parameter	Type	Description
file *	binary	The XML invoice file to render as PDF.
language	string	Language for PDF labels and date formatting. Values: `en`, `de`, `fr`. Defaults to `en`.
logo	binary	Your logo, printed top-left as the create endpoints print it: a PNG or JPEG file part of at most 2 MB and 4 megapixels, re-encoded before embedding. Send either this or `logoUrl`, not both.
logoUrl	string	Public URL of your logo instead of the file itself, with the same limits. The API fetches it with the same protections as the create endpoints' `pdfUrl`.
includeQrCode	boolean	Prints an EPC QR code (GiroCode) in the payment section, exactly as the create endpoints' `options.includeQrCode` does: a banking app turns it into a pre-filled SEPA credit transfer. Printed when the invoice is in EUR, carries a valid IBAN, is paid by credit transfer and has an amount due. Defaults to `false`.

Content-Type: multipart/form-data

Accepted input

The syntax is resolved from the root element and its namespace, before any Business Term is read. Nothing needs to be declared in the request.

Root element	Detected as	Covers
<CrossIndustryInvoice>	UN/CEFACT CII	All EN 16931 CII profiles from MINIMUM through EXTENDED, the XML extracted from a ZUGFeRD or Factur-X PDF, and XRechnung in CII syntax.
<Invoice>	UBL invoice	Peppol BIS Billing, PINT, national CIUS profiles such as NLCIUS and EHF, XRechnung in UBL syntax, and plain EN 16931 UBL.
<CreditNote>	UBL credit note	The same UBL profiles as above, rendered with credit note labelling.

An XML document with any other root namespace is rejected with a 400 and errorCode 4008, and a non-XML upload with a 400 and errorCode 4004. To render the XML inside a ZUGFeRD or Factur-X PDF, pull it out first with POST /v1/extract/xml and post the result here.

Headers

Header	Value
Authorization *	Bearer YOUR_API_KEY
Content-Type	multipart/form-data

Response

200 Rendered PDF

Returns the rendered PDF as a binary file.

Content-Type: application/pdf

Frequently Asked Questions

Which XML documents does this endpoint accept?

UN/CEFACT Cross Industry Invoice (CII), UBL Invoice, and UBL CreditNote. Because XRechnung is a CIUS on top of those two syntaxes, XRechnung files are accepted in either binding without anything extra to declare. The same applies to the other EN 16931 CIUS profiles carried in UBL, such as Peppol BIS Billing, PINT, NLCIUS, and EHF.

How does the API know which syntax I sent?

From the root element and its namespace. A CrossIndustryInvoice root in the UN/CEFACT namespace is read as CII; an Invoice or CreditNote root in the OASIS UBL namespace is read as UBL. There is no format parameter to pass and no content sniffing beyond the root element, so detection is deterministic.

How does this differ from the format-specific render endpoints?

It does not differ at all in behaviour. POST /v1/render/xrechnung/to/pdf, POST /v1/render/cii/to/pdf, and POST /v1/render/ubl/to/pdf are permanent aliases that reach the same action with the same auto-detection, so any of the four paths renders any supported file. Existing integrations keep working unchanged; the generic path simply saves you from choosing a route when the incoming syntax varies.

Are the format-specific paths deprecated?

No. They are permanent aliases with no removal date. Keep them if the explicit route documents intent in your codebase, or if you want the request log to record which format a caller believed it was sending.

Can I control the language of the PDF?

Yes. Pass the optional language form field with en, de, or fr to set the field labels and date formatting. It defaults to en. The invoice content itself is rendered exactly as it appears in the XML and is never translated.

Is the rendered PDF legally valid?

No. The PDF is a visual representation of the XML data for human readability. It is not a hybrid PDF/A-3 and carries no embedded XML, so the original invoice XML remains the authoritative document for compliance and tax purposes.

Is rendering the same as validating?

No. Rendering reads whatever Business Terms the document carries and lays them out; it does not check the file against EN 16931 or any national Schematron rule set. A file that renders may still be non-compliant. Use the matching /v1/validate endpoint when you need a compliance verdict.

Is the invoice data stored?

No. Files are processed entirely in memory and deleted immediately after the PDF is returned. No invoice data is written to disk or retained.

What is the maximum file size?

20 MB. Invoice XML files are typically a few kilobytes, so this limit is unlikely to be reached in practice.