Skip to content

Security and data

relay holds your customers' private conversations. This page explains where they are stored, how they are protected, who can read them and when they are deleted.

Report a vulnerabilitySee sub-processors
DraftVersion 0.1-draftEffective [EFFECTIVE DATE]Last updated November 12, 2026

The path of one message

From the phone that holds your number to the inbox in your browser.

  1. On the phone

    WhatsApp encrypts the message end to end, up to every device linked to the number.

    The relay gateway is one of those linked devices.

  2. The linked device

    Like WhatsApp Web, the gateway decrypts the message so you can read it.

    It runs in Frankfurt with no public address, and its session keys never leave it.

  3. Stored in Frankfurt

    Text goes to the database, media to a private bucket.

    Both are deleted once they pass your plan's window: 90, 180 or 365 days.

  4. Read in your browser

    Media opens through a signed link that expires after 5 minutes.

    Links are issued per request, never cached and never logged.

Draft for legal reviewThis page describes how relay works today, but counsel has not reviewed it yet. Items in [brackets] are facts we still have to confirm.

In short

  • Everything relay stores stays in the EU, in Frankfurt.
  • Media is private and opens only through links that expire after 5 minutes.
  • WhatsApp session keys stay in the gateway's own storage, never in the relay database.
  • Messages and media are deleted when they pass your plan's window, or when you delete the number.
  • Logs, error reports and analytics never contain message content or phone numbers.

1Where your data lives

relay runs in Frankfurt, Germany. The application, its database, its queues and the WhatsApp gateway run on DigitalOcean (region FRA1); the private media bucket is on Google Cloud (region europe-west3), in the same city.

Your WhatsApp data (messages, media, contacts and groups) is stored only there. It leaves the region when you ask it to: when you open the inbox, call the API, or receive webhooks at the URLs you choose.

Every relay address, including this website, the app and the API, sits behind Cloudflare, which protects it from attacks and carries the traffic between you and our servers. On that path, message data passes through Cloudflare's global network and may be handled outside the EU [CONFIRM REGION]. Webhooks we send you go straight from our servers to your URLs.

Account and billing details also reach a few service providers, such as our payment processor. Each one is listed with its location and the safeguard that covers the transfer.

2How messages and media are stored and read

Message text, contacts and chat details are stored in our PostgreSQL database. Photos, videos, documents and voice notes are stored in a private bucket: no file in it is public, and no file has a permanent link.

To show you a file, relay issues a signed link that expires after 5 minutes. Links are issued per request, only to your signed-in session or to your API keys, and they are never cached or logged. The one exception is a file you send: the gateway gets its own link, valid for 10 minutes, to fetch it.

Files you send go straight from your browser to the bucket, through a one-time upload link that fixes the file's type and size and expires after 15 minutes. A file received from WhatsApp stays on the gateway for at most 30 minutes, until relay moves it into the bucket.

About WhatsApp's end-to-end encryption

WhatsApp encrypts messages end to end between the devices linked to a number. The relay gateway is one of those devices, just as WhatsApp Web is when you open it in a browser: it decrypts messages so the inbox and the API can show them. From that point on, the protections on this page apply.

3Encryption in transit and at rest

Traffic to relay
HTTPS only, TLS 1.2 or later. Your connection ends at Cloudflare, which opens a second encrypted connection to our servers and checks their certificate. Our servers ask Cloudflare for its client certificate and are set to refuse any connection that doesn't present it. Plain HTTP is redirected, and browsers are told to use HTTPS for a year, subdomains included (HSTS).
Webhooks we send you
Signed with HMAC-SHA256 over the timestamp and the body, and sent only to public HTTPS addresses.
Webhook secrets, proxy passwords, stored API replies
Sealed with AES-256-GCM before they are written to the database.
API keys
Stored as a SHA-256 hash with a short display prefix. The full key is shown once, when you create it.
Databases and the gateway's volumes
Encrypted at rest by DigitalOcean. [CONFIRM WITH PROVIDER]
The media bucket
Encrypted at rest by Google Cloud. [CONFIRM WITH PROVIDER]

relay doesn't add its own encryption to message text and media beyond our providers' storage encryption: the service has to read them to show your inbox, search it and deliver your webhooks.

4Who can access your data

In this version, each organization has a single owner account. There are no team seats yet.

  • Signing in requires a verified email address and a password of at least 10 characters.
  • Resetting the password signs out every open session.
  • Session cookies travel over HTTPS only.
  • API keys carry scopes (read, send, admin), can be given an expiry date, and can be revoked at any time.

Audit log

relay records administrative actions with who made them, when, and from where (the web app, the API or our operations tools): API keys created or revoked; webhook endpoints created, changed, disabled or deleted, and their secrets rotated or revealed; number connections, logouts and deletions; proxy changes; organization settings changes and deletion requests; plan changes; and our own operator actions, such as switching an organization's sends off. Entries hold ids and changed settings, never secrets or message content.

Our staff

[STAFF ACCESS POLICY: who at relay can reach production systems and message data, on what grounds, and how each access is approved and recorded.]

Our operations tools run on an internal port with no public route, and refuse every request that doesn't carry an operator token.

5WhatsApp session isolation

When you link a number, WhatsApp gives the linked device a set of session keys. Whoever holds them can read and send as that number, so they are kept apart from everything else.

  • Session keys are stored only in the gateway's own storage, on volumes encrypted at rest [CONFIRM WITH PROVIDER]. They never enter the relay database.
  • The gateway has no public address. Only relay's API and workers can reach it, and each gateway instance answers only to its own key.
  • Events from the gateway are signed (HMAC-SHA512) and arrive on an internal port that is never exposed to the internet.
  • Sessions are named with internal ids, never with phone numbers.
  • Deleting a number logs its session out of WhatsApp and removes it from the gateway.

The gateway also keeps a working copy of each linked number's chats, which it needs to import history and catch up after a reconnect. It lives on the same volume and is deleted with the session. [GATEWAY STORE RETENTION]

The network around it

Every service in our cluster starts from a deny-all network policy and is allowed only the connections it needs. Calls to your webhook URLs can't reach private address ranges or the cloud's metadata service.

With the optional proxy add-on, a number's encrypted WhatsApp connection goes out through an address in the number's country.

6Retention and deletion

Messages and media
Your plan's window: 90 days on Starter, 180 on Growth, 365 on Business. A nightly job deletes anything older, and history import never brings older chats in.
Without an active plan
The shortest window, 90 days.
Webhook delivery log
30 days, or your plan's window if it is shorter.
Chats, contacts and profile pictures
Kept as long as the number is in your organization, and deleted with it.
Stored replies to API retries
Replayable for 24 hours, then removed by the next nightly purge.
A number you delete
Its chats, messages, contacts and media are deleted, and its WhatsApp session is logged out.
An organization you delete
Every number, as above, plus its API keys, webhook endpoints and delivery log, usage counters and audit log. The owner gets an email when it's done.

Deletions run in the background as soon as you confirm them. Your user account survives an organization's deletion, so you can create a new organization later. Billing records are kept for [ACCOUNTING RETENTION PERIOD] to meet accounting obligations.

Backups held by our hosting provider may keep deleted data until they expire. [BACKUP RETENTION PERIOD]

7Logging without message content

Logs, error reports, analytics events and audit entries carry ids, counts, error codes and statuses. That rule binds every part of relay.

What they contain

  • Internal ids of organizations, numbers and messages
  • Counts and durations
  • Error codes and statuses

What they never contain

  • Message text or captions
  • Phone numbers or WhatsApp ids
  • Contact or group names
  • Media files or media links

Error reporting (Sentry) and product analytics (PostHog, EU cloud) run only in production, never from a developer's machine. Error reports are set not to collect personal data, and analytics is limited to a short list of account events, such as a sign-up, a number connected or a plan change, identified by internal ids.

The emails we send about your numbers describe their status without naming the phone number or any contact. The gateway logs warnings only, because its routine lines would include chat ids.

8Abuse controls

relay is built for conversations people expect, not for campaigns. These limits protect your numbers and the people you write to.

  • No bulk or broadcast sending: one request sends one message to one conversation.
  • Each number sends a few seconds apart, with random jitter.
  • A newly linked number starts with a low daily limit that rises over its first two weeks.
  • A daily limit on messages to people who have never written to the number.
  • Monthly send quotas per plan, and API rate limits per key: a per-minute budget set by your plan and a burst cap of 20 requests per second.
  • A kill switch per organization: when we turn it on, every send is refused, from the inbox and the API alike, and the change is recorded in the audit log.

9Reporting a vulnerability

If you find a security issue in relay, write to support@wrelay.site. Our security.txt file is at https://wrelay.site/.well-known/security.txt.

What to include

  • What you found, and where
  • The steps to reproduce it
  • The impact you think it has

While you test

  • Use only accounts and numbers you own.
  • Don't access, change or delete other people's data.
  • Don't message people who haven't agreed to it, and don't degrade the service for others.

We acknowledge every report within [RESPONSE TIME] and keep you informed until the issue is fixed. [SAFE HARBOR TERMS] [BUG BOUNTY TERMS, IF ANY]

10Certifications and compliance

relay doesn't hold a security certification today: no ISO 27001 certificate and no SOC 2 report. We will list one here only once it has been issued.

We process personal data under the GDPR and Moroccan law 09-08. CNDP declaration: [CNDP NUMBER].

For the WhatsApp data you process through relay, you are the controller and relay is your processor. The Data Processing Agreement sets out what we commit to.

11Contact

Security reports
support@wrelay.site
Privacy questions
support@wrelay.site
Company
[COMPANY LEGAL NAME], [REGISTERED ADDRESS]