Scope
The website's Contact and Request a demo forms post to POST /v1/public/leads, served by the leads service (services/leads) and mounted in the control plane. This is vendor lead data about prospects — it is unrelated to customer production data, which never reaches DataNivra Cloud.
What is stored
| Table | Contents | Retention |
|---|---|---|
leads_submissions | name, email, company, optional job title, message and demo date, consent + notice version, pseudonymous client key | deleted after 365 days (configurable) or on request |
leads_events | hash-chained audit events: lead id, event type, reason code, pseudonymous client key — no personal data | kept for audit |
leads_outbox | pending/sent notification status | deleted with the lead |
Protection
Requests are size-limited, rate-limited per client, screened with a honeypot and a minimum fill time (plus an optional challenge verifier), validated against the v1 contract, and refused without consent. Error responses carry field paths and codes, never the submitted values.
Operator tasks
- Deliver notifications:
python -m datanivra_leads dispatch-outbox(every minute). The destination comes from secret configuration; if it is not configured, nothing is sent. - Enforce retention:
python -m datanivra_leads purge-expired(daily). - Deletion requests: pipe the address to
python -m datanivra_leads eraseon standard input (never as a command-line argument, which process listings and job logs would record).
The public privacy notice describes the same behaviour for visitors.