The PDF download waits instead of asking you to poll
GET .../invoices/{id}/pdf now waits for the PDF and answers 200. Prefer: wait=0 keeps the old pure polling behaviour.
The 202 on GET /v1/companies/{company_id}/invoices/{invoice_id}/pdf meant "poll this endpoint until it answers 200": a loop to write, a backoff to tune, and a PDF that took longer than if the request had simply waited. It waits now.
By default the request waits up to 10 seconds and answers 200 with the URL. 202 becomes the exception, and it carries Retry-After.
What else changed
- You choose the wait, with a standard header.
Prefer: wait=Nbounds it;Prefer: wait=0gives you the pure poll you have today, unchanged. Asking for more than the cap is capped, and the response tells you what was applied inPreference-Applied. A preference that is not understood is ignored. - Both cases that produced
202now wait — no file yet, and a file rendered by an earlier template — each queueing its regeneration once before waiting. - What can never have a fiscal PDF still fails immediately. A draft or a scheduled invoice answers
400at once: you are not charged the latency of a request that cannot succeed. - Nothing you have breaks. If you already poll, you keep polling — you will just usually get the
200on the first call.
Endpoints
- GET/v1/companies/{company_id}/invoices/{invoice_id}/pdfWaits up to 10s and answers 200; honours Prefer: wait=N
Where to go next
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.
VeriFactu is a fact of the taxpayer, not a flag per invoice
Whether an invoice reaches the AEAT is now decided by the NIF's regime at issue time. The per-invoice flag and three response fields are gone.