API Reference
The InvoiceXML API lets you convert PDF invoices into structured e-invoicing formats and validate compliance, all via simple REST endpoints.
Base URL
https://api.invoicexml.com
All endpoints are relative to this base URL. The API is served over HTTPS only.
Authentication
Authenticate every request by including your API key in the
Authorization header.
Authorization: Bearer YOUR_API_KEY
Versioning
The API is versioned in the URL path. Every endpoint lives under the
/v1 prefix, and the current version is
v1. Additive changes (new endpoints, new optional fields) ship within v1 without notice; any breaking change would be released under a new version prefix, so a working integration keeps working.
How the API is organized
The API is grouped into a handful of capabilities. Each endpoint either returns JSON (validation reports, extracted data) or a binary file (a generated PDF or XML invoice). Pick the group you need from the table below or the sidebar.
| Capability | What it does | Endpoints |
|---|---|---|
| Create | Build a compliant e-invoice from structured JSON. | POST /v1/create/{format} |
| Validate | Check a PDF or XML invoice against EN 16931 and Schematron rules. | POST /v1/validate/{format} |
| Transform | Turn a plain PDF invoice into a structured e-invoice using AI extraction. | POST /v1/transform/to/{format} |
| Convert | Switch between EN 16931 XML syntaxes (CII, UBL, XRechnung) and hybrid PDF wrappers (Factur-X, ZUGFeRD). Every source-target combination is its own explicit route. | POST /v1/convert/{source}/to/{target} |
| Render | Produce a human-readable PDF from invoice XML. | POST /v1/render/{format}/to/pdf |
| Extract | Pull structured data out of a PDF as JSON or XML. | POST /v1/extract/{json|xml} |
| Embed | Attach a CII XML invoice into a PDF/A-3 container, branded as Factur-X or ZUGFeRD. | POST /v1/embed/{facturx|zugferd} |
| Parse | AI-parse any PDF invoice into structured JSON. | POST /v1/parse/json |
HTTP Status Codes
Every response carries a standard HTTP status code indicating the transport-level outcome. When a request fails, the body is a structured error object. See the
Error Handling
guide for the response envelope, the errorCode categories, and code samples.
| Status | Meaning |
|---|---|
| 200 | Success, the request completed and the result is in the response body. |
| 400 | Bad Request, validation or processing error. See errorCode and errors for details. |
| 401 | Unauthorized, missing or invalid API key in the Authorization header. |
| 422 | Unprocessable Entity, the file format is not supported for this endpoint. |
| 429 | Too Many Requests, rate limit exceeded. Check the Retry-After header. |
| 500 | Internal Server Error, an unexpected error occurred. Retry the request or contact support. |
OpenAPI schema
Every endpoint, request parameter, and response schema is published as a machine-readable OpenAPI document, generated from the live API so it never drifts from the implementation.
https://api.invoicexml.com/v1/openapi
Point your tooling at that URL to generate a typed client library (openapi-generator, NSwag, Kiota), import the full API into Postman or Insomnia, or drive contract tests against your integration.
Interactive API explorer
Prefer to explore the API in your browser? An interactive reference, powered by Scalar and rendered from the OpenAPI document above, is available at:
https://api.invoicexml.com/v1/scalar
Browse every endpoint, inspect request and response schemas, and send live requests with your API key without leaving the page. It is the fastest way to get a feel for a response shape before you write any code.
Code examples on GitHub
Ready-to-run example projects in several languages are maintained in a public GitHub repository. Clone it for end-to-end samples covering authentication, file upload, generation, validation, and error handling that you can run against your own API key.