Data flows — ZevSend¶
How customer data enters, moves within, and leaves ZevSend. Cross-product flows are also summarised at cross-product/data-flows.md.
Inbound¶
| From | What flows in | Trigger | Lawful basis |
|---|---|---|---|
| Developer via browser → ZevID | OAuth identity token (accountId, email, name) |
Customer signs in to console.zevsend.com |
Contract |
| ZevID → ZevSend | Identity claims on token verification (per-request) | Every API call from the dashboard | Contract |
| Customer application → ZevSend public API | Send request payloads (from, to, subject / body, template_id + variables) on /v1/emails, /v1/sms, /v1/whatsapp, /v1/verify |
Customer-application-driven sends | Contract |
| AWS SES → ZevSend (via SNS) | Delivery / Bounce / Complaint / Send / Reject feedback for each dispatched email — carrier message id, recipient, diagnostic code, timestamp | Per-message after SES processing | Contract (necessary to provide deliverability feedback) |
| SMS carriers → ZevSend | Delivery status callbacks per carrier protocol | Per-message after carrier dispatch | Contract |
| WhatsApp (Meta Cloud API) → ZevSend | Delivery + read receipts | Per-message after Meta dispatch | Contract |
| ZevPay → ZevSend | Payment confirmation webhooks (invoice paid, refund, payment-method updated) | ZevPay events | Contract |
| ZevID → ZevSend (ZPIP webhooks) | Account / enrollment lifecycle events | ZevID events | Contract |
Outbound¶
| To | What flows out | Trigger | Lawful basis |
|---|---|---|---|
| ZevSend → ZevID | Internal API calls to resolve accountId → user profile fields, enrollment writes, Zev Credit balance reads / debits |
Per-request and per-team-state-change | Contract |
| ZevSend → ZevPay | Invoice + subscription create / update; payment-method tokenisation requests | On billing events (subscription renewal, plan change, refund) | Contract |
| ZevSend → AWS SES | Outbound email SendEmailCommand — from (with composed display name when applicable), to, subject, body, configuration set, team-id tag |
Customer send through /v1/emails |
Contract (the feature the customer is using) |
| ZevSend → SMS carriers | Outbound SMS via per-carrier API — sender id / number, recipient phone (E.164), body | Customer send through /v1/sms |
Contract |
| ZevSend → WhatsApp (Meta Cloud) | Outbound WhatsApp template send — phone, approved template name + language, positional parameters | Customer send through /v1/whatsapp |
Contract |
| ZevSend → ZevCloud (via ZPIP) | DNS-record add / remove requests scoped to a single customer-owned domain — used to publish DKIM, MAIL FROM MX, SPF, DMARC, bounce-routing records on a domain whose authoritative DNS lives at ZevCloud | Customer setup of a zevcloud-managed sending domain | Consent (per-scope grant captured at ZevID) |
| ZevSend → customer webhook endpoints | Event envelopes (email.sent, email.delivered, email.bounced, email.complained, email.failed, sms.*, whatsapp.*, verify.*) — message public id, recipient, status, carrier reason |
Carrier-feedback ingestion | Contract |
| ZevSend → centralised exception + log monitoring | Stack traces, scrubbed request context, structured security-event log lines (may include accountId, IP, UA) |
App errors + security events | Legitimate interest |
Internal diagram¶
graph LR
Dev((Customer app)) -->|HTTPS API| ZevSend
User((Dashboard user)) -->|OAuth| ZevID
ZevID -->|identity| ZevSend
ZevSend -->|enrollment sync| ZevID
ZevSend -->|invoice + subscription| ZevPay
ZevPay -->|payment confirmation| ZevSend
ZevSend -->|ZPIP DNS add/remove| ZevCloud
ZevSend -->|SendEmail| SES[AWS SES]
SES -->|delivery / bounce / complaint via SNS| ZevSend
ZevSend -->|SMS dispatch| SMSCarriers[SMS carriers]
ZevSend -->|WhatsApp dispatch| Meta[Meta Cloud API]
ZevSend -->|outbound webhook delivery| CustomerWebhook[Customer endpoints]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) |
| Application runtime | Customer (any) → Coolify host (Hetzner, Ashburn VA) | SCCs / DPA with Hetzner |
| Email dispatch | Customer (any) → AWS SES (eu-west-1 default) → recipient mail server (anywhere) | AWS DPA + recipient-MX-server-controlled |
| SMS dispatch | Customer (any) → SMS carrier (region-dependent) → mobile network operator (anywhere) | Per-carrier DPA |
| WhatsApp dispatch | Customer (any) → Meta Cloud API (Meta-controlled global infra) → recipient WhatsApp client (anywhere) | Meta's published DPA |
| Centralised logging | Customer (any) → log-monitoring provider | Provider's published DPA + SCCs |
The compliance details for each vendor including SCC posture live with the DPO office; this page summarises the data movement, not the contractual coverage.