Render invoice
The invoice as a PDF, to send to the customer. The response is the document, not JSON; if you need a PDF with the XML embedded, see Factur-X in the interoperability area.
Request body
The request body is the whole document, sent raw (Content-Type: application/xml) — not an object with fields.
Query parameters
How it behaves
- The document can also be sent as a file:
multipart/form-datawith thefisierfield (curl -F fisier=@document.xml), instead of the raw body. The file content becomes the request body, so the result is identical; options stay in the query string, and any other form field next tofisierreturns422 camp_necunoscut. - Takes a CIUS-RO invoice XML and returns its PDF — the visual, human representation of the document. The response is binary (
application/pdf), not JSON. - The PDF is generated locally and in-memory: no external service is called and nothing is written to disk. As with the other routes, it is zero retention — the XML received is not logged.
- Useful for showing the invoice to a human (customer, accountant) or archiving it alongside the filed XML. The XML remains the official document; the PDF is only its representation.
- An XML that cannot be parsed returns
422with a JSON body{eroare:{cod,mesaj,camp}}(not a PDF), so the error stays readable.
What it is for
- Displaying or printing the invoice for the customer.
- Archiving a legible PDF alongside the filed CIUS-RO XML.
- Attaching the PDF to an invoice-notification e-mail.
Response structure
All fields below live inside data.
Content-Type: application/pdf), not a JSON envelope.
Response examples
body: @efactura.xml
The response is a binary document, not JSON: application/pdf, 23,5 KB in this example.
body: @efactura-corectata.xml
The response is a binary document, not JSON: application/pdf, 23,5 KB in this example.
body: @efactura-stornare.xml
The response is a binary document, not JSON: application/pdf, 22,3 KB in this example.
body: @efactura-intracomunitara.xml
The response is a binary document, not JSON: application/pdf, 25,3 KB in this example.
Error codes
| Code | Slug | When it occurs |
|---|---|---|
| 401 | neautentificat | Token missing, invalid, expired or revoked. |
| 403 | feature_indisponibil | The current plan does not include the feature the route depends on. |
| 422 | xml_invalid | The body is not parsable XML. The error comes as JSON {eroare:{cod,mesaj,camp}}, not as a PDF. |
| 429 | cota_depasita | The plan's monthly quota has been exceeded (see Retry-After). |
Errors in the Anaf module use the same envelope as the rest of the platform, with two extra fields: {eroare: {cod, mesaj, camp, request_id}}. eroare.cod is stable and is what you branch on; on validation (422) the code is case-specific: xml_invalid, xml_nu_e_factura, unitate_necunoscuta, luna_invalida and so on. camp points at the offending field when one can be identified.
{
"eroare": {
"cod": "xml_invalid",
"mesaj": "The body is not parsable XML. The error comes as JSON {eroare:{cod,mesaj,camp}}, not as a PDF.",
"camp": null,
"request_id": "0199c1f0-6e1a-7c3d-9b2f-4a8e5d1c7b04"
}
}