Skip to content

Cross-product shared services

External processors used ecosystem-wide rather than per-product. Each product's third-parties.md references this page rather than duplicating the same row N times.

How to use this from a product section

If your product uses one of these services through ZevID (the typical case for email, SMS, file uploads), put a row in your third-parties.md like "We use ZevID's email/SMS/file-upload surface. We do not hold a direct relationship with ZeptoMail/Termii/Cloudflare-R2." The processor relationship is between ZevOP Technologies Limited and the vendor; this page is the canonical record.

If your product uses the service directly (your own API key, your own delivery domain, etc.), list it in your third-parties.md like any other processor — the shared-services arrangement doesn't apply.

Email — ZeptoMail

Every Zev product's transactional email goes through ZeptoMail under ZevOP Technologies Limited's account. There is no per-product email vendor — all signup OTPs, sign-in alerts, password-change notifications, welcome emails, etc. dispatch through the same vendor with product-aware templates.

  • Processor: ZeptoMail (a Zoho product)
  • Auth: ZEPTO_MAIL_TOKEN env on ZevID's backend; products call ZevID's internal email surface rather than holding their own token.
  • What gets sent: recipient email, recipient first name, event-specific template variables. No full account profile, no KYC fields, no financial figures unless explicitly designed into the template.

SMS — Termii

Every Zev product's SMS dispatch — phone verification, SMS MFA, product-driven re-verification — goes through Termii under ZevOP Technologies Limited's account. Products use ZevID's internal phone-verification surface rather than integrating Termii directly:

  • End-user phone verification + SMS MFA: ZevID's /v1/account/phones/* user-facing endpoints (the user owns this flow in the account portal).
  • Product-driven re-verification (e.g. ZevCloud confirming the user before granting a free deployment): the product calls ZevID's /v1/internal/users/:accountId/phones/:phoneId/send-code then /confirm-code. ZevID's Termii integration dispatches the SMS.

The model: ZevID is the SMS hub, Termii is ZevID's processor, the consuming product is downstream of ZevID. Other products do not hold direct Termii relationships and should not list Termii as one of their direct processors.

  • Processor: Termii (Nigerian SMS provider)
  • Auth: TERMII_API_KEY env on ZevID's backend
  • What gets sent: E.164 phone number (leading + stripped), 6-digit code, sender id
  • Region: Nigeria

Per-product contributor note: if your product needs the user to verify a phone for an anti-abuse or step-up flow, document the use case + frequency in your product's processing.md so the DPO can see what triggers SMS at your boundary. The vendor row stays here; the purpose (why you trigger the SMS) is yours to document. Suggested template:

### Purpose: Phone re-verification for <feature>

**What it is.** One sentence on why this product needs SMS.
**Trigger.** What user action / system event causes it.
**Frequency.** Rough estimate (per-user, per-month, etc.).
**Vendor relationship.** None — we use ZevID's internal phone-verification surface.
See [Cross-product / Shared services → SMS](../../cross-product/shared-services.md#sms--termii).

File uploads — Cloudflare R2

Every Zev product's file upload (profile pictures for ZevID; product images, document attachments, etc. for other products) goes into a Cloudflare R2 bucket under ZevOP Technologies Limited's account. The bucket is shared across products; each product uses its own directory prefix inside the bucket.

  • Processor: Cloudflare R2
  • Auth: R2_ACCESS_KEY_ID / R2_SECRET_ACCESS_KEY env on ZevID's backend
  • Bucket model: single shared bucket, per-product directories

Per-product contributor note: if your product uploads files, document what kinds of files + size limits + which fields they're stored against in your product's data-inventory.md. The vendor row stays here.

Observability — Better Stack

Every Zev product (where wired) sends application exceptions + structured logs to Better Stack. ZevID's deployment uses both: the SENTRY_DSN env points at Better Stack's Sentry-compatible ingest (the Sentry SDK works without needing a separate Sentry account), and LOGTAIL_TOKEN points at Better Stack's log ingest.

  • Processor: Better Stack (Sentry-compatible exception ingest + Logtail log aggregation)
  • What gets sent: stack traces (request scrubber strips body), structured log lines (may include accountId, IP, UA in security events)

Hosting / database — Neon-on-AWS

ZevID's primary database runs on Neon's managed Postgres service on AWS us-east-1 (N. Virginia). Other Zev products may use a different database or region — document yours per product.

  • Region: AWS us-east-1
  • Backups: Neon's default configuration (continuous WAL-based point-in-time recovery)

App hosting — Hetzner VPS (Ashburn, VA)

The NestJS application processes for ZevID run on Hetzner VPS infrastructure under ZevOP Technologies Limited's control, located in Ashburn, VA. Hetzner is a processor of the host but does not have access to data on the disk; Zev controls the operating system, deploys, and secrets.

  • VPS provider: Hetzner
  • Region: Ashburn, Virginia, US

What this page does NOT do

  • Doesn't replace per-product vendor lists. Each product still owns its third-parties.md and lists every direct vendor relationship there.
  • Doesn't track DPA dates centrally — those live with the DPO.