Contract cancellation
The letter, the dispatch confirmation, postal tracking, the counterparty response.
4–8 documents per cancellation
Lethra is the retention and dispatch-evidence layer for platforms that make bureaucracy invisible. Every compliance document becomes one encrypted deposit — held for as long as the applicable regime requires, then forgotten with a certificate that proves it.
The plaintext never reaches us. The key never transits us. A breach of our storage exposes bytes that decrypt to nothing.
Partners encrypt client-side. We hold ciphertext and the metadata you choose to send.
Per-deposit keys in a hardware-backed store. Destroy the key, the bytes become noise.
Published daily roots, external timestamps, offline verifier. It works if we are gone.
German data centres. An EU entity. No US-jurisdiction storage path.
01 · The problem
Cancelling a contract takes thirty seconds. Somebody then has to keep the paperwork long after the customer has forgotten it happened — and increasingly that somebody is the platform that made those thirty seconds possible.
A generation of companies built their product on removing paperwork from the user's day. Cancellation services. Tax filing apps. Insurance claims in a chat window. Prescriptions without a waiting room.
Each works by absorbing a process that used to be the user's problem. That absorption is the value. It is also the liability, and the two are the same event.
The obligation did not vanish. It landed one layer down, on a platform built for speed rather than for keeping things.
Where the trail usually lives
That holds until someone asks two things.
Can you produce the document, unaltered, with evidence of when it arrived. And when the retention period ends, can you prove you destroyed it.
Neither is a storage problem. Both are evidence problems.
02 · The product
Four API primitives. Four retention regimes. No interface your customers have to learn, no migration project, no consultant. The shape of every Lethra integration is the same.
/v1/deposits
curl https://api.lethra.io/v1/deposits \
-u "sk_live_…:" \
-H "Idempotency-Key: $(uuidgen)" \
-F "regime=GoBD-DE" \
-F "ciphertext=@cancellation.bin"
{
"deposit_id": "dep_01HM9C7A4Y2RXKQF3T8BVW7H6N",
"state": "stored",
"regime": "GoBD-DE",
"receipt": {
"hash": "sha256:9a7f2c84…",
"signature": "day:2026-09-02:MEUCIQD…"
}
}
No plaintext ever transits Lethra.
/v1/deposits/{id}/events
curl https://api.lethra.io/v1/deposits/dep_01HM…/events \
-u "sk_live_…:" \
-d type=fax.dispatched \
-d "payload[receiver]=+4930…"
{
"event_id": "evt_01HM9CB2Q8T4N…",
"deposit_id": "dep_01HM9C7A4Y2RXKQF…",
"type": "fax.dispatched",
"signature": "day:2026-09-02:MEQCIF…"
}
No plaintext ever transits Lethra.
/v1/deposits/{id}
curl https://api.lethra.io/v1/deposits/dep_01HM… \
-u "sk_live_…:" \
-H "Accept: multipart/mixed" \
-o bundle.multipart
{
"deposit_id": "dep_01HM9C7A4Y2RXKQF…",
"integrity": "verified",
"events": 3,
"attestation": { "root": "2026-09-01", "proof": [ "…" ] }
}
No plaintext ever transits Lethra.
/v1/deposits/{id}/forget
curl https://api.lethra.io/v1/deposits/dep_01HM…/forget \
-u "sk_live_…:" \
-d mode=scheduled
{
"certificate_id": "cert_01HM9D4X…",
"state": "forgotten",
"mode": "scheduled",
"original_hash": "sha256:9a7f2c84…",
"pdf": "https://verify.lethra.io/c/cert_01HM9D4X…"
}
No plaintext ever transits Lethra.
03 · How it works
Three moments matter in a deposit's life. Here is what happens in each, and what you get back.
Your platform encrypts the document with a key that never transits our systems, then calls Store with the ciphertext and a declared regime.
You keep the key. There is no escrow and no recovery path through us.
We seal it again under a per-deposit key held in a hardware-backed store, replicate it across German regions, and return a signed receipt.
Every operation is committed to a daily Merkle root, signed and published.
When the regime's window closes — or on your instruction — the per-deposit key is destroyed. Every remaining copy becomes noise.
You receive a Certificate of Forgetting: PDF for the auditor, JSON for your system.
Why destroying a key beats deleting a file
A delete call returns a status code. Between it and the bytes being unrecoverable sits a chain you cannot inspect — replicas, snapshots, backups whose own retention outlives the thing you deleted, provider-side tiering. Destroying the key changes the status of every copy at once, and it is a claim about one small object inside a boundary built to support it. Read the long version.
04 · Verification
Most compliance tooling asks you to trust the vendor. The receipt lives in their dashboard, the verification link points at their domain, and if they disappear the evidence becomes a screenshot. We built the opposite.
Scan
A code on the document resolves to a plain answer: this was registered, on this date, under this regime.
Anyone
Full chain
The complete signature chain, including the inclusion proof tying one document to a published daily root.
A lawyer or a sceptic
Offline
A command-line verifier run against the receipt and a published key, with no connection to us at all. This one keeps working if we are gone.
A court or an auditor
There is a commercial argument against building this — it makes us replaceable. That is the point. A trust layer that requires trust in the trust layer has not solved the problem it was hired for.
05 · Who it is for
The bureaucracy still exists; the platform makes it invisible. Lethra holds what the platform leaves behind. Six verticals across DACH, each producing a cluster of retainable artefacts per transaction.
The letter, the dispatch confirmation, postal tracking, the counterparty response.
4–8 documents per cancellation
Declaration, submission confirmation, tax-office receipt, correspondence.
3–6 documents per filing
Supporting evidence, dispatch logs, insurer correspondence, settlement.
5–15 documents per claim
Consultation log, prescription, delivery confirmation.
2–5 documents per interaction
Application paperwork, bank dispatch, response handling.
4–10 documents per application
Applications, official correspondence, decisions.
5–10 documents per transaction
You declare the regime at deposit time; the engine owns the schedule, the scheduler, and the pause switch for when preservation is required beyond it. Your integration holds a string, not date arithmetic.
06 · Build status
We are pre-launch and we would rather state that precisely than let a landing page imply otherwise.
The API is not callable yet. There is no live endpoint, no self-serve signup, and no production traffic. Everything below is a build milestone, not availability.
In progress
The four primitives run end to end against all four regime engines, with receipts that verify. Not a launch — your production documents do not belong in it yet.
Next
Full lifecycle against synthetic load, restore drills, deliberate failure testing on the storage layer. We would rather find those problems than have a partner find them.
Then
A limited number of test partners, closely held, at reduced rates in exchange for feedback we can act on.
September 2026
A ninety-minute working session on your document lifecycle, a demo against your case, and an honest answer about whether this is worth doing for you yet.
There is no soft launch running quietly behind this and no stage left off the list. If a date moves, we will post about it on the day rather than letting it pass quietly.
07 · Writing
We publish the reasoning behind the architecture — including the trade-offs that do not flatter us.
·5 min
Where a company is registered and where its data physically sits are separate questions with separate answers. Both of ours are deliberate, and the reasoning is the kind a compliance reviewer will ask for anyway.
Read →
·5 min
No Kubernetes, no service mesh, no event bus, no dashboard for end users, no document management features. Each omission was a decision with a reason, and the reasons are more useful than the list.
Read →
·5 min
Retention rules differ by jurisdiction and change over time. Putting that behind a declared regime keeps it out of partner code, and makes the schedule an auditable artefact rather than a scattered assumption.
Read →
08 · Questions
Compliance is a posture, not a feature. Below is ours.
Because the plaintext belongs to you. You encrypt the document on your side, with a key we never see, before calling Store. We hold the ciphertext and the metadata you provide. If a supervisory authority wants the content, they ask you — we can prove what was stored, when, and that it has not been altered, and we cannot reveal what we never held.
Infrastructure. Lethra holds compliance-relevant documents for as long as the applicable regime requires, ends their existence verifiably when that period closes, and emits a cryptographic certificate for both events. No tokens, no coins, no chain. Encryption here is data security, used the way Stripe uses TLS.
The deposit is forgotten. Three modes: scheduled, a data-subject request acted on under your instruction, or crypto-shred where you discard your own key. All three are irreversible and produce a Certificate of Forgetting — a signed PDF and JSON record stating that the deposit no longer exists, with a SHA-256 anchor.
That question is genuinely contested and we will not pretend otherwise. Supervisory authority views differ and the analysis varies by jurisdiction and context. What we claim is the technical property: the key is destroyed inside a boundary built to make extraction infeasible, and the certificate records precisely what was done so that you, as the controller, have something concrete to argue with.
We hold ciphertext and hardware-backed key material, and we run a documented incident response. Because we never hold plaintext, a worst-case breach of our object store leaks ciphertext only. Your encryption key remains where it always was — on your side.
None yet, and we say so rather than implying otherwise. Formal audit processes take time and money we have deliberately spent on the architecture first. Anyone selling you a compliance product on the basis that it makes your compliance question disappear is being dishonest.
You are the controller. We are the processor. We act on your instruction — a forget call names its mode, so the record shows what was requested and on what basis. We do not adjudicate between competing obligations and we do not offer a setting that quietly picks a side.
The offline verification path keeps working. Daily roots are published and hash-chained, anchored to a timestamp from an independent authority, and a command-line verifier checks a receipt against a published public key with no connection to our systems. We also recommend partners keep their own copy of both the document and the receipt.
We have a standard data processing agreement ready for the point where your legal team asks for one, and pilot partners get it as part of onboarding. Custom terms are a conversation, not a blocker.
09 · Contact
This is a pre-signup phase, not general access. A limited number of platforms, and what you get before anything is integrated is a workshop and a product demo against your own case.
You get a ninety-minute working session with the people who built this: a map of your document lifecycle, a demo of the four primitives against your document types and volume, and an honest answer about whether this is worth doing for you yet.
We get to build against a real integration rather than an imagined one. Partners in this phase shape the metadata model, the webhook format, and what a certificate has to contain before your auditor accepts it.
The trade is substantially reduced rates in exchange for feedback we can act on, not a testimonial.
Prefer email
office@lethra.ioTell us what your platform does and roughly what volume of documents it produces. That is the whole application — no form gate, no deck, no qualifying call before the actual conversation.
If your platform generates documents somebody has to keep, the conversation starts now rather than in September.
Email only, for launch news. The application above is the route to a workshop.