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.
A correction to the contract, not to the API. The phone of a customer, an invoice's issuer and recipient, and the company profile declared the same 9-character minimum and character pattern that a request has to meet. A stored number does not always meet them: it may have arrived through a payment provider or a bulk import, or have been saved before the rule existed.
A client that validated responses against the contract threw away the whole list when it hit one such number.
What else changed
- Responses use
Phone, which only states the 20-character maximum. Read the field defensively and do not assume it parses. - Requests use
PhoneInput, with the rules the API enforces on the way in: 9 to 20 characters, digits, spaces, dashes, parentheses and an optional leading+. Nothing you send is judged differently. - What to do. If you generate a client from the contract, regenerate it. Response models lose the pattern check and request models keep it.
Where to go next
Member grants carry the company's name
Each grant in a member's response and in the grants list now carries `company_name` next to `company_id`, so you can name the company without resolving every id against the account's companies. It is optional and may be `null` for a company that has no name yet. It never falls back to the id.
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.