Addresses can be missing, and accept more characters
issuer.address is optional and is no longer filled with invented values, and one character set governs every address field.
Three changes to how addresses travel, all of them visible from outside.
The one that can break you: issuer.address leaves required. It is omitted when the company has not declared its address yet. It always arrived before — but it arrived made up: a newly registered company got street: "Sin especificar", postal_code: "00000", values nobody had ever entered, passing the contract as if they were data.
What else changed
issuer.addressmay now be absent. It affectsissueron invoice responses, previews included. If you readissuer.address.streetdirectly, check thataddressexists first. If you print the issuer's address on a document, the gap is now visible instead of covered with false text — the fix is for the company to complete its fiscal address, which the issuing gate already requires, not for the API to invent one.RecipientData.addresswas already optional and does not change.Customer.addressis still required.numberwas already announced separately and is unchanged here — see The street number is no longer required in an address.- One character set for every address field.
street,city,provinceandcountryeach accepted a slightly different set, so the same address was valid or not depending on which field it landed in —C/Xic de l'Anyéwas rejected as a street and accepted as a city. There is now a single set, the union of everything any field already accepted: typographic apostrophes, parentheses and&work everywhere. - Nothing was renamed and no stored row was touched. An address that exists arrives exactly as before, and one that does not name a country is still read as Spanish — that is a declared convention, not invented data.
Endpoints
- GET/v1/companies/{company_id}/invoices/{invoice_id}issuer.address is omitted when the company has not declared one
- POST/v1/companies/{company_id}/customersevery address field shares one character set
Where to go next
Payment connections are addressed by id
The `{provider}` path segment becomes `{connection_id}` on nine payment-connection paths. The old paths are gone, with no coexistence window.
The API serves its own spec
`GET /v1/openapi.yaml` and `/v1/openapi.json` serve the public contract — the same document this reference is built from, no API key needed.