Data flows — ZevCloud
How customer data enters, moves within, and leaves ZevCloud. Cross-product flows are also summarised at cross-product/data-flows.md.
Inbound
| From |
What flows in |
Trigger |
Lawful basis |
| End-user via browser → ZevID |
OAuth identity token (accountId, email, name) |
Customer signs in to console.zevcloud.net |
Contract |
| ZevID → ZevCloud |
Identity claims on token verification (per-request) |
Every API call from the dashboard |
Contract |
| ZevPay → ZevCloud |
Payment confirmation webhooks (invoice paid, refund, payment-method updated) |
ZevPay events |
Contract |
| NameSilo / NIRA → ZevCloud |
Registry status changes (transfer-completed, expiry reminders, registry-side WHOIS updates) |
Registrar callbacks + scheduled polls |
Legal obligation (ICANN/NIRA reporting) |
| Cloudflare → ZevCloud |
Out-of-band DNS-record deletion notifications (DNS reconciler picks these up during sync) |
Background reconciliation |
Contract |
| ZevWorkspace via ZPIP → ZevCloud |
DNS-record add/remove requests scoped to a single customer-owned domain (used to provision DKIM, verification TXT, etc. for the customer's ZevWorkspace mailbox setup on their ZevCloud-managed domain) |
User-driven setup in ZevWorkspace |
Consent (per-scope grant captured at ZevID) |
Outbound
| To |
What flows out |
Trigger |
Lawful basis |
| ZevCloud → ZevID |
PUT /v1/internal/users/:accountId/enrollments/zevcloud (enrollment + tier + team-count metadata) |
On signup, on team-state changes |
Contract |
| ZevCloud → ZevPay |
Invoice + subscription create/update; payment-method tokenisation requests |
On billing events (purchase, renewal, refund) |
Contract |
| ZevCloud → NameSilo |
Domain register / renew / transfer requests, registrant contact PII, EPP auth codes |
Customer domain action |
Contract + legal obligation |
| ZevCloud → NIRA (Cocca EPP) |
Same shape as NameSilo but for .ng domains; we are a direct accredited registrar |
Customer .ng-domain action |
Contract + legal obligation |
| ZevCloud → Cloudflare |
DNS zone create/update/delete + DNS records on customer's behalf |
Customer DNS edits + automatic platform records |
Contract |
| ZevCloud → Forward Email |
Domain registration + MX/SPF/verification TXT writes when customer enables email forwarding. Aliases themselves are created from explicit customer dashboard action only |
Customer toggle + customer-added forward |
Contract |
| ZevCloud → ZeptoMail |
Transactional emails (deploy/billing/domain notifications) |
System events |
Contract |
| ZevCloud → ZevWorkspace via ZPIP webhooks |
dns.record.deleted event when a record attributed to ZevWorkspace is removed (so ZevWorkspace can update its state) |
DNS reconciler observation |
Contract |
| ZevCloud → Better Stack |
Sentry-compatible exception ingest + structured logs (may include accountId, IP, UA in security-event log lines) |
App errors + log writes |
Legitimate interest |
Internal diagram
graph LR
User((Customer)) -->|OAuth| ZevID
ZevID -->|identity| ZevCloud
ZevCloud -->|enrollment sync| ZevID
ZevCloud -->|invoice + subscription| ZevPay
ZevPay -->|payment confirmation| ZevCloud
ZevCloud -->|register / renew| NameSilo[NameSilo registry]
ZevCloud -->|register / renew| NIRA[NIRA registry .ng]
ZevCloud -->|DNS CRUD| Cloudflare
ZevCloud -->|email-forwarding domain + aliases| ForwardEmail[Forward Email]
ZevCloud -->|transactional email| ZeptoMail
ZevWorkspace -->|ZPIP DNS add/remove| ZevCloud
ZevCloud -->|ZPIP webhooks| ZevWorkspace
Cross-border movement
| Hop |
Origin → destination |
Mechanism |
| Customer data at rest |
Customer (any) → Neon (AWS us-east-1) |
SCCs with the relevant Zev / Neon / AWS entities (held by the DPO) |
| Customer container hosting |
Customer (any) → Hetzner (Falkenstein, DE) |
SCCs / DPA with Hetzner |
| Email forwarding relay |
Customer (any) → Forward Email infra |
Forward Email's published DPA |
The compliance details for each vendor including SCC posture live with the DPO office; this page summarises the data movement, not the contractual coverage.