API v1.1.0 — Refactored invoice recipient & payment_info, new series defaults
Invoice recipient and payment_info schemas have been refactored to use structured objects with allOf composition. This change normalizes the API and enables future extensibility. Also adds new series defaults endpoints.
Invoice recipient and payment_info schemas have been refactored to use structured objects with allOf composition. This change normalizes the API and enables future extensibility. Also adds new series defaults endpoints.
What breaks
- PUT /v1/invoices/{invoice_id} schema change —
recipientandpayment_infonow useallOfcomposition referencingRecipientandPaymentInfoschemas. The fields (nif,legal_name,iban,method, etc.) remain available but the schema path changed from inline properties to a $ref. Clients using generated SDKs may need to regenerate. - SDK regeneration recommended — If you use generated clients from the OpenAPI spec, regenerate them to pick up the new schema references. The underlying fields are the same; only the structure (and how the SDK types represent them) has changed.
What else changed
- Structured
recipientandpayment_info— PUT /v1/invoices/{invoice_id} now usesallOfcomposition withPaymentInfoandRecipientschemas. Fields likenif,legal_name,iban,methodare still available via the referenced schemas, but the structure changed from inline to composed. Regenerate your SDK if you use one. - New series defaults endpoints — POST /v1/configuration/series/defaults and GET /v1/configuration/series/defaults-status allow setting and checking per-document-type default series.
- Idempotency-Key header — Now formally documented on POST /v1/customers.
- Invoice email options — All invoice endpoints now return
email_configandsend_automaticallyfields in responses.
Endpoints
- PUT/v1/invoices/{invoice_id}recipient and payment_info now use allOf composition — update your request payload structure
- POST/v1/configuration/series/defaultsSet default series per document type
- GET/v1/configuration/series/defaults-statusCheck which series have defaults configured
Where to go next
API v1.2.0 — VeriFactu validation pack, public error catalog, metadata filters, RD-ley rates, BIZUM
Third wave of VeriFactu compliance hardening: invalid fiscal combinations are now rejected at request time with specific 422s, a public error-code catalog is available at docs.beel.es with stable per-code pages, Stripe-style metadata filtering on the invoices list, RD-ley 11/2022 temporary rates (5% IVA + 0.625% recargo de equivalencia), BIZUM as a new payment method, and several Stripe Connect refinements.
API v1.0.3 — VeriFactu exemptions, document types, stricter validations
Second round of VeriFactu compliance improvements: invoice lines can now carry an explicit exemption reason, the tax-types endpoint exposes the full LIVA exemption catalog, invoice series can be typed, and the `id_otro` VeriFactu rules are now enforced with specific error messages.