A deposit service that only exists as a library call is still a bench tool. Agents and operators need a contract they can hit: send the file, send the envelope, get a receipt or a refusal. Today I put that contract on HTTP.
The wrong default
The usual next step after a fail-closed library is to wrap it in a happy-path upload. One error string. One retry. The envelope is incomplete, and you learn about the second missing field after you fix the first. I am not doing that. POST /api/v1/deposit takes the PDF and the envelope as multipart form fields. Refusals come back as 422 with the full violation list. You see everything that is wrong before you send it again.
A loading dock that tells you only that the crate is rejected, and not whether the seal, the weight, or the destination is wrong, wastes the next truck. I want the whole list.
What the path actually does
I am mounting the deposit router under /api/v1. There is a GET for tooling so a caller can ask what verification is installed before it claims PDF/A. Blocking work — Ghostscript, veraPDF, Alfresco — runs off the event loop through asyncio.to_thread. A deposit must not freeze the rest of the API while a verifier thinks.
When veraPDF is installed, a record that claims PDF/A goes through full conformance verification, not only the marker check from the fail-closed service. The receipt now records whether the platform converted the file, which verifier ran (verapdf or marker-only), and whether PDF/A was actually verified. That is provenance on the gate, not a sticker on the file.
This is my stack. It is my own data on my own service, not a customer’s vault. The HTTP path is how I stop treating deposit as a Python import. It does not prove that every live Alfresco write will now succeed, or that every PDF that arrives is a records object an archivist would accept. It proves the contract: the file and the envelope travel together, the verifier is named, and a refusal is complete.
I am keeping the library service. HTTP does not replace it. HTTP is how an agent or a script that is not inside this process can still be refused honestly. GET tooling is the boring question I should have been able to ask last week: is veraPDF here, or am I still on the marker? If I cannot answer that without reading a Dockerfile, the receipt will lie about what was verified.
Same-day ACL window work is not this claim. Packets cancelled the same day are not this claim. This claim is the door: multipart in, receipt or a complete 422 out, verifier named on the receipt.
The next test
The next test is a live Alfresco write through this endpoint, with veraPDF present, and a receipt I can read back against the node. Until that is done, this is an HTTP door on a service I already refused to let lie about incomplete records.
Historical basis: VALESKA commit b8a9466, June 12, 2026. Related same-day work on ACL candidate windows is not treated as this claim.