OAuth2 leaves the public contract
OAuth2 is gone from the spec. Each operation now states the scope it requires in its own description. API key auth is unchanged.
The OAuth2 security scheme is gone from the published spec: from the global security block, from securitySchemes, and from every operation that declared it. Nothing changes at runtime — the authorization endpoints, the tokens already issued and the per-endpoint scope enforcement are all exactly as they were.
What replaces it in the document is more useful than what it removed: every operation now says which scope it needs, in prose you can read in this reference.
What else changed
- Why it goes. There was no way for a third party to register a client, so the spec offered a flow on hundreds of operations that only we could actually use. Documenting a mechanism nobody can exercise is worse than not documenting it.
- Where the scope lives now. Each operation's description carries a line like
**Required scope:** invoices:write, and the full scope catalogue — which used to hang off the OAuth2 flow — is a table in the description ofApiKeyAuth. - Nothing to do. API key authentication (
Authorization: Bearer beel_sk_…) is untouched. If you generate a client from the spec, the new one simply stops offering an OAuth2 flow you could not use. - It can come back. The day third-party application registration exists, OAuth2 returns to the contract with its catalogue and its flow.
Where to go next
The census is checked before the invoice is numbered
Issuing with VeriFactu on checks the recipient against the AEAT census first: an uncensused recipient answers `422`, and no number is spent.
Three filters returned the wrong rows
A literal `%` in a filter value dropped the filter. `series_code` matched any series containing the code. Sorting customers ignored the documented field names. **Only `series_code` changes a response you may rely on today.**