Changelog

Typed request schemas on every parse endpoint

If you generate a client from our OpenAPI specification, it now knows what to send.

Previously, the 65 country- and format-specific parse endpoints carried no usable request schema. A generated SDK turned that into an untyped, optional parameter — the required data field disappeared, and calling the method with no arguments compiled cleanly. Only the server rejected it.

What changed

• Every parse endpoint declares its request body: data (required, Base64) and filename (optional)
• Invoice line items are a named type, InvoiceLineItem, instead of an unresolvable reference — so the 36 fields of a line item, including nested subItems, are documented and typed
• Errors are a named ErrorResponse type, and the format options echoed back on a generated document are an AppliedFormatOptions type
• The specification carries an absolute server URL, so generated clients reach the API without extra configuration

Do I need to act? No endpoint, field or behaviour changed — this is the specification catching up with what the API always did. Regenerate your client to pick up the types.

New endpoints

• POST /api/v1/invoice/{countryCode}/{format}/embed — embed a generated e-invoice XML into your own carrier PDF
• GET /api/v1/verifactu/declaracion and GET /api/v1/verifactu/chain/{vatId}/export — Spanish VeriFactu declaration and chain export