Skip to content
Replyz docs
Not available yet. Replyz is built and tested, but not deployed: https://api.replyz.io is the planned address and does not answer yet. These pages describe the API as it is built today and may change before launch.

Security and privacy

This page describes Replyz as it is built. It is not deployed yet, and the terms and privacy notice are not published yet.

Data stored in the EU

Section titled “Data stored in the EU”

Replyz stores customer data at rest in EU-jurisdiction storage:

Data Where
The original message, exactly as received Cloudflare R2, EU jurisdiction
Attachments Cloudflare R2, EU jurisdiction
Parsed messages, threads and events A Cloudflare Durable Object per account, EU jurisdiction
Account and inbox records Cloudflare D1, EU jurisdiction
The queue between receiving and parsing Cloudflare Queues, EU jurisdiction. A queue job holds only ids, the storage key, the size, the time and the recipient, not the message or the sender address

Exception: mail for youreplyz.com is received through Cloudflare Email Routing, which keeps its own activity log (sender, recipient and subject) on Cloudflare’s side. We found no setting to turn it off, and whether that log stays in the EU is not confirmed.

The code runs on Cloudflare Workers, which may execute outside the EU.

API keys

Section titled “API keys”
  • Replyz stores only a keyed hash (HMAC-SHA256) of each API key and its first 12 characters. It never stores or logs the full key, so it cannot show it again.
  • Unknown and revoked keys get the same 401 answer, so the API does not reveal whether a key exists.
  • The API sends no CORS headers: browser JavaScript on another origin cannot call it.
  • Every JSON response, errors included, carries Cache-Control: no-store.

Signups

Section titled “Signups”
  • Signup needs a proof of work instead of a human check, plus per-network limits (Limits).
  • Replyz never stores or logs the IP address of a signup. It keeps only a keyed hash of the network (one IPv4 address or one IPv6 /64), for its counters and on the account.

Addresses are never reused

Section titled “Addresses are never reused”

A deleted inbox leaves a permanent record of its address: a keyed hash, not the address itself. The address is never issued to anyone again, so nobody can receive mail meant for a deleted inbox. See Inboxes.

Untrusted mail

Section titled “Untrusted mail”

Email content is untrusted input. Replyz removes most hidden content from text and scores prompt-injection risk (heuristics that lower the risk but do not make mail safe; see the known gaps), flags risky attachments, serves every attachment as a download, and never fetches links or images. The sender is not authenticated in this version. See Untrusted content and safety.

Rejected mail does not say why

Section titled “Rejected mail does not say why”

Mail is rejected with one text for every reason (unknown address, deleted inbox, inactive account, size, monthly cap), so a sender cannot tell which reason applies. See Receiving mail.

Retention

Section titled “Retention”

Automatic deletion after fixed retention periods is planned and not built yet: today nothing is deleted automatically. The mail of a deleted inbox is hidden from every route at once; erasing it is planned.

These docs

Section titled “These docs”

docs.replyz.io has no cookies, no trackers and no third-party scripts or fonts. Search runs in your browser. Your browser stores only your light/dark theme choice (starlight-theme, kept locally) and, for the current tab only, which sidebar sections are open; neither is ever sent to us.

Contact

Section titled “Contact”