Trust Center
What we store, where, and what we never keep.
Lemtika renders documents from your data and hands back the file. Your system stays the system of record — we keep as little as possible, in the EU, and we tell you plainly what that means. Below is exactly what is retained, what auto-deletes, and what is never stored.
Retained
The durable record
Render and receipt metadata only — that a render happened, its template, timestamps, an output fingerprint (SHA-256), and the credit charge. This is the account record. It never includes the document payload.
Ephemeral
Auto-deletes on a short clock
Rendered outputs are downloadable for a short window — 24 h for a single render, 7 d for a batch — then auto-deleted. The input valuesyou send through the web app (kept up to 24 h) or a batch run (up to 7 d) are held only for that window, then content-erased. This runs on a best-effort hourly sweep — never ours to keep, though not a hard guarantee.
Never stored
The direct render API
Values sent to the direct /v1/render API are used in memory and never written to disk. Render and request payloads are never logged. (This card is the direct API — web-app and batch inputs are transiently retained; see Ephemeral.)
Still hardening
We would rather tell you what is not finished than imply it is. These are in progress:
Encryption at rest — in progress
Our database currently relies on host-level disk security in the EU. Dedicated encryption at rest is in progress and not yet in place.
Background-removal cache expiry — in progress
When a render removes an image background, the cutout is cached to speed re-renders. An automatic expiry for that cache is in progress.
How it is enforced
EU data residency
Outputs and data are stored in the EU (Germany). The service fails to start if its storage is not EU-resident — so a non-EU deploy cannot silently happen.
Tenant isolation
Every record is scoped to your account. A request can never reach another tenant's data — a mismatched lookup returns nothing, not someone else's record.
Fail-closed rendering
An unsafe or invalid request errors rather than emitting a broken document. Approve a design once; a valid request always produces the known result.
Have a compliance question?
Read the Terms, or get in touch — we answer data-handling questions directly.