# 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.

Sep 17, 2026 · Improved

The `verifactu` block of an invoice declared a `chaining_hash`, described as the chaining hash with the previous invoice. It has never travelled in a single response: the contract declared it and the server never sent it. It is gone from the guides and from the examples.

This is a correction of the document, not a change to the API. If you read it, you were reading `undefined` before and you will read `undefined` after.

## What else changed

- **Nothing stops being sent, because nothing was being sent.** Any client that treated it as optional — which is the only way it could have worked — is unaffected.
- **If you generate a client from the machine-readable contract, regenerate it.** The schema still declares the field until the next contract sync, so a generated model may carry a `chainingHash` that is always empty. It is safe to drop.
- **The chain itself is not affected.** VeriFactu chaining is maintained on the submission record; what is going away is a field that promised to show you a link in it and never did. `invoice_hash` is unchanged and keeps fingerprinting the invoice.
- **`skip_reason` is in a similar position**, though it stays: it is still published, but only invoices issued before VeriFactu became a fact of the taxpayer carry a value. Nothing writes it now, so on invoices issued today it is always `null`.

## Endpoints

- `GET /v1/companies/{company_id}/invoices/{invoice_id}` — The verifactu block no longer declares chaining_hash

## Where to go next

- [Submission states](/verifactu/submission-states)
- [VeriFactu is a fact of the taxpayer](/changelog#verifactu-is-an-account-fact)

---

Full OpenAPI spec: https://docs.beel.es/api/openapi