The VeriFactu records of an invoice, each with its own status
GET …/invoices/{invoice_id}/verifactu-records lists the registration and, after a void, the cancellation — each with its own submission_status, so you can tell whether AEAT accepted the cancellation.
The verifactu block of an invoice summarises its registration. When you void the invoice, submission_status moves with the cancellation, but invoice_hash, registration_number and registered_at keep describing the registration record — so the block could not tell you whether AEAT had accepted the cancellation, or refused it and why.
The new resource lists every record submitted to AEAT for the invoice, ordered by registered_at: the REGISTRATION first and, if the invoice was voided, the VOID after it. Each carries its own submission_status, registration_number, registered_at and, when AEAT reported something, error_code and error_message.
Nothing changes on the invoice resource: the verifactu block keeps the same fields and the same meaning.
What else changed
- A
VOIDrecord ends inVOIDED, notACCEPTED. While AEAT has not replied it isPENDING; a refused cancellation isREJECTED, witherror_codeanderror_messageexplaining why. invoice_hashandqr_urltravel only onREGISTRATIONrecords. A cancellation has neither.- Each record's
idis theverifactu_registration_idof theverifactu.status.updatedwebhook event, so a notification can be matched to the exact record it reports on. - Voiding while the registration is still
PENDINGis allowed. The cancellation is sent once the registration is accepted; until then the list shows only theREGISTRATIONrecord, and theVOIDone appears when the cancellation goes out. - The collection is closed: no pagination, no
page/limit, the whole set on every response. An invoice never submitted — a draft, or one outside VeriFactu — answers200with an empty list.
Endpoints
- GET/v1/companies/{company_id}/invoices/{invoice_id}/verifactu-recordsRegistration and cancellation records, each with its own submission_status
Where to go next
A phone number in a response no longer promises the input rules
The contract stops declaring `minLength` and `pattern` on `phone` in responses; they move to `PhoneInput`. The server sends exactly what it sent before.
chaining_hash leaves the documentation
`verifactu.chaining_hash` was declared but never sent, so it is being withdrawn. No response changes: the server behaves exactly as before.