Data Processing Agreement

This agreement is part of the Terms of Service of letr.dev and is concluded by accepting them.

1. Parties and purpose

1.1 Between the customer who accepted the Terms of Service (the "Customer", the controller) and Viascom GmbH, Weissbadstrasse 8b, 9050 Appenzell, Switzerland (the "Processor", "Viascom").

1.2 This agreement sets out the processing of personal data that Viascom carries out for the Customer when the Customer sends email through letr.dev. It is the processor contract required by Art. 9 of the Swiss Federal Act on Data Protection (FADP) and, where the GDPR applies to the Customer, by Art. 28 para. 3 GDPR.

1.3 Where this agreement uses GDPR terms (controller, processor, personal data, data subject, personal data breach, supervisory authority), they also mean the corresponding FADP terms (Verantwortlicher, Auftragsbearbeiter, Personendaten, betroffene Person, Verletzung der Datensicherheit, EDÖB). References to the GDPR apply to a Customer only as far as the GDPR applies to that Customer; the FADP applies to Viascom in every case.

1.4 Private customers: where a private person uses letr.dev purely for personal or household purposes, the FADP (Art. 2 para. 2 lit. a) and the GDPR (Art. 2 para. 2 lit. c) do not apply to that person's processing. This agreement still applies to describe how letr.dev handles the data, and the security, breach and deletion duties in it bind Viascom.

2. Roles

2.1 The Customer is the controller for the email it sends through letr.dev: the sender and recipient addresses, subjects, content, attachments, tags and headers, the delivery events about them, the suppression list of its account and any data in webhook deliveries. Viascom processes this data as the Customer's processor, only on the Customer's instructions.

2.2 Viascom is the controller, and this agreement does not apply, for: the Customer's account, user, billing and contact data; the records of operator actions and abuse reports in the account history; the metadata of the Customer's email that an operator exports for an abuse or account takeover case; aggregated bounce and complaint rates and sending counts used for limits, billing and reputation; and letr.dev's own system mail to the account owner. The privacy policy at letr.dev/privacy describes this processing.

3. Subject matter, duration, nature and purpose

3.1 Subject matter: the transmission of the Customer's email to the recipients' mail servers, the recording and provision of delivery events, the keeping of a suppression list and the delivery of webhooks, through the letr.dev HTTP API, SMTP relay, MCP server and dashboard.

3.2 Duration: for as long as the Customer has a letr.dev account, and until the deletion under clause 12.

3.3 Nature: storage for the periods in clause 4.3, transmission, logging of delivery events, display, provision through API and webhooks, masking and deletion.

3.4 Purpose: sending the transactional email the Customer hands over and reporting back what happened to it. Viascom does not process the data for its own purposes except as controller under clause 2.2, and it does not track opens or clicks.

4. Data and data subjects

4.1 Categories of personal data: email addresses and display names of senders and recipients; subject lines; message content and attachments as the Customer composes them, which may contain any kind of personal data the Customer puts there, including sensitive data if the Customer sends such content; tags and custom headers; message IDs; delivery events with timestamps and the responses of receiving mail servers; suppression entries with their reason; webhook payloads containing the above.

4.2 Categories of data subjects: the Customer's users, customers, employees, contacts and anyone else the Customer sends email to or from.

4.3 Retention within the processing: message content, attachments included, is kept with the email's metadata for the same period: shown for 30 days and purged after 32, or 365 and 367 while the message history add-on is paid, under the same lapse and withdrawal rules. It is stored encrypted (Annex 2). letr.dev's queue keeps it at most 3 days after the send time, and a scheduled email (up to 7 days ahead) keeps its content from the request until its send time. If the receiving mail server defers the email, the mail server's queue keeps it at most 3 more days after the hand-off. Sender, recipients, subject, tags and delivery events are kept 30 days and purged after 32, or 365 days and purged after 367 while the Customer's message history add-on is paid, and those older than 32 days are purged 14 days after it lapses, or within a day after a withdrawal from it; webhook deliveries 32 days; suppression entries until the Customer removes them or the account is deleted. Backups under clause 12.3 can hold all of this for up to 52 weeks after its deletion (database) or 7 days (mail server). Outside the database, recipient addresses are in the mail server's delivery logs, which are deleted automatically there after 14 days and kept up to 7 days longer in its backups, in the web server's error log at Datadog, which can contain email addresses from requested URLs and is kept 30 days, and in the app server's web server logs, which hold the same URLs and are kept until log rotation removes them.

5. Instructions

5.1 Viascom processes the data only on the Customer's documented instructions. The documented instructions are: the Terms of Service, this agreement, the Customer's API calls, SMTP submissions and MCP tool calls, and the settings the Customer makes in the dashboard (domains, webhooks, suppression list, ceiling, erasures, the message history add-on).

5.2 Viascom may depart from the instructions only where Swiss law or the law of the EU or a member state that applies to Viascom requires it. In that case Viascom informs the Customer of the requirement before processing, unless the law prohibits it.

5.3 Viascom informs the Customer at once if, in its view, an instruction infringes the FADP, the GDPR or other data protection law. Viascom may then suspend the instruction until the Customer confirms or changes it.

5.4 Instructions that go beyond the service as documented are not possible; the service has no interface for them.

6. Confidentiality

6.1 Viascom allows access to the data only to persons who need it to provide the service and who are bound by a confidentiality duty by contract or by law. Access to production systems is personal, logged where the system supports it, and every operator action on a Customer's account is recorded in the account history.

6.2 Viascom does not read the content of messages to operate the service. On suspicion of a breach of the Acceptable Use Policy (abuse, spam, scam), an operator may open the content of individual emails. Every such access requires a written reason, is recorded in the account's history, and the Customer sees the time of each access on the email in the dashboard. Operators otherwise work with metadata (recipients, subjects, tags, events) and with the headers of abuse reports.

7. Security

7.1 Viascom takes the technical and organisational measures in Annex 2, keeps them current and improves them as technology advances. They are designed for the risk of the data described in clause 4: email that may contain any content, with content and metadata kept for up to about a year with the message history add-on, sent in high volume.

7.2 The Customer is responsible for what it puts in an email and for its own systems: the safekeeping of API keys and SMTP credentials, the choice of recipients, the use of the suppression list and the security of its webhook endpoints. The Customer should not send data that needs stronger protection than email provides.

8. Sub-processors

8.1 The Customer gives general authorisation for Viascom to use the sub-processors in Annex 3. The current list is at letr.dev/subprocessors.

8.2 Viascom informs account owners by email at least 30 days before a new or replaced sub-processor starts processing the Customer's data, naming the sub-processor, its location, the purpose and the transfer basis. The Customer may object within those 30 days for data protection reasons. If the parties find no solution, the Customer may terminate the contract with effect before the change takes effect; prepaid fees for the time after the termination are refunded. If the Customer does not object within 30 days, the sub-processor counts as authorised.

8.3 Viascom imposes on every sub-processor, by written contract, data protection duties that give the data at least the protection of this agreement, and remains fully liable to the Customer for the sub-processor's performance.

8.4 Urgent replacement: where Viascom must replace a sub-processor at once to keep the service secure or running, it informs the Customer as soon as possible and the Customer keeps the objection and termination right of clause 8.2.

9. International transfers

9.1 The Customer's data is stored and processed on servers in Germany (Hetzner). Encrypted backups of the database are stored by Contabo in the EU (clause 12.3). Germany and the other EU states are adequate under Swiss law, so no transfer safeguard is needed.

9.2 Cloudflare (USA) carries API traffic in transit, including the recipients and content of email sent through the API. Datadog (USA) receives the operational log of the mail server with email addresses masked, and the web server's error log, which can contain email addresses that appear in requested URLs. The transfer basis for both is the EU-US and the Swiss-US Data Privacy Framework, under which both are certified. Google (Google Workspace) holds letr.dev's mailboxes in Ireland and in Google's data centres worldwide, including the USA; support requests, emails to letr.dev and abuse reports about the Customer's emails arrive there and can contain the Customer's personal data. For the USA the transfer basis is the EU-US and the Swiss-US Data Privacy Framework, under which Google LLC is certified; for other countries it is the standard contractual clauses in Google's Cloud Data Processing Addendum.

9.3 WorkOS (USA) processes dashboard sign-in data, for which Viascom is the controller; it does not process the Customer's email data. The transfer basis is the European Commission's standard contractual clauses with the amendments for Switzerland.

9.4 Should the Data Privacy Framework be invalidated, Viascom will rely on the standard contractual clauses with the sub-processors concerned or, where that is not possible, inform the Customer under clause 8.2.

9.5 Viascom does not otherwise transfer the data outside Switzerland, the EU or the EEA, and does not transfer it to any country without an adequacy decision of the Swiss Federal Council and, where the GDPR applies, of the European Commission, except under clauses 9.2 and 9.3.

10. Assistance to the Customer

10.1 Data subject requests: Viascom forwards to the Customer without undue delay any request from a data subject that concerns the Customer's email and does not answer it itself, unless the Customer instructs it to. The Customer handles access, rectification, erasure and objection requests with the tools letr.dev provides: the message and event views in the dashboard and API, the recipient search, DELETE /v1/recipients/{email} for erasure (which replaces the address with erased in every email, event and webhook delivery of the account; the content of every email addressed to the erased recipient or naming it in its subject or tags is deleted at once, while a scheduled email that only names it in its subject or tags is still sent at its time and kept in letr.dev's queue until then) and the suppression list. The erasure reaches neither the backups under clause 12.3 nor the delivery logs, the error log and the app server's web server logs under clause 4.3; these are deleted on their own, the backups after up to 52 weeks after deletion (database) or 7 days (mail server), the delivery logs after 14 days, the error log after 30 days and the web server logs when log rotation removes them. If Viascom restores data from a backup, it tells every Customer the time the restored data reflects (clause 12.3). Viascom cannot repeat recipient erasures itself, so the Customer repeats every recipient erasure made at or after that time from its own records. For anything the tools do not cover, Viascom assists on request at cost.

10.2 Security, breach notification, data protection impact assessments and prior consultation: Viascom assists the Customer with the information it holds, taking into account the nature of the processing. Viascom publishes its measures (Annex 2), its sub-processors and its retention periods so that most assessments can be made from the published material. Assistance beyond that is provided on request; Viascom may charge its reasonable costs for effort beyond a few hours.

10.3 Supervisory authorities: Viascom cooperates with the FDPIC and, where the GDPR applies, with the competent supervisory authority, and informs the Customer of any request from an authority that concerns the Customer's data, unless the law forbids it.

11. Personal data breach

11.1 Viascom informs the Customer without undue delay after becoming aware of a personal data breach that affects the Customer's data.

11.2 The notice goes by email to the account owner and describes, as far as known at the time and completed in stages where needed: the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, the measures taken or proposed, and a contact. Viascom documents every breach, its effects and the remedial action, and keeps the documentation at least 2 years.

11.3 The Customer decides whether and how to notify a supervisory authority and the data subjects; Viascom supports it under clause 10.2. Viascom does not notify authorities or data subjects on the Customer's behalf unless instructed.

12. Deletion and return

12.1 During the contract the Customer can export the data letr.dev holds through the API and the dashboard at any time: delivery events of the Customer's message history (30 days, or 365 with the add-on), the content of each email in that history (except the content a recipient erasure deleted, clause 10.1), the suppression list, domains and webhook settings.

12.2 30 days after the contract ends, however it ends (termination, withdrawal, decline), Viascom deletes the account with every record keyed to it: email metadata, content and events, the suppression list, domains and DKIM keys, API keys, webhooks and their deliveries, the MCP activity, the account history and the dashboard users. Viascom confirms the deletion on request.

12.3 Backups: the database is backed up to Contabo's object storage in the EU with a full backup every week, a differential backup on the other days and continuous archiving of its write-ahead log, encrypted with AES-256 before the backup leaves the database servers; full backups are kept 52 weeks, about one year. The app server keeps no customer data at rest apart from its web server logs (clause 4.3) and is not backed up. The mail server has Hetzner's daily server backups, of which the last 7 are kept. Backups may therefore hold the data for up to about one year after deletion; they are not restored except for disaster recovery. A restore returns the data to an earlier time. Viascom handles the data lost by it as a personal data breach under clause 11 and tells every Customer the time the restored data reflects. Emails that were due before the restore started are not sent again; letr.dev's queue also fails and deletes restored content more than 3 days past its send time. Scheduled emails due after the restore started are sent at their send time unless the Customer cancels them again. Changes the Customer made since that time are lost, and the Customer makes them again: recipient erasures, cancelled scheduled emails, revoked API keys, removed webhook endpoints and domains, and suppression entries added since. Viascom applies again, from Stripe's records, the contracts that ended or started since that time. The scheduled deletion jobs run again on the restored data and delete on their own what is past its period: email metadata and events older than 32 days, or 367 days while the message history add-on is paid, webhook deliveries older than 32 days, and accounts that ended more than 30 days before. Stored content older than its period is deleted by the same jobs. A recipient erasure is not repeated on its own (clause 10.1).

12.4 Viascom keeps what the law requires it to keep: billing records for 10 years under Art. 958f of the Code of Obligations (in Viascom's accounts), the breach documentation under clause 11.2 and the log of authority requests. Those records contain no email content and no recipient addresses.

13. Audits

13.1 Viascom gives the Customer the information needed to show compliance with this agreement: this agreement with its annexes, the published sub-processor list, the status page, the runbook sections on breach handling on request, and answers to a reasonable written questionnaire once a year.

13.2 Where that is not enough for a specific, documented reason, or where a supervisory authority requires it, the Customer or an independent auditor bound to confidentiality may audit Viascom's processing on site or remotely, once a year, with 30 days' written notice, during business hours, without disrupting operations and without access to other customers' data. The Customer bears the costs of the audit and reimburses Viascom's reasonable effort, unless the audit reveals a material breach of this agreement. Hetzner's data centres are audited by Hetzner; Viascom provides Hetzner's published attestations instead of access.

14. Liability and precedence

14.1 Liability under this agreement follows clause 13 of the Terms of Service. The limitation does not apply where data protection law provides otherwise, in particular to the liability of each party towards data subjects under Art. 82 GDPR.

14.2 In a conflict between this agreement and the Terms of Service on the processing of personal data, this agreement prevails. In a conflict between this agreement and mandatory data protection law, the law prevails.

14.3 The law and the place of jurisdiction of clauses 16.4 and 16.5 of the Terms of Service apply, with their consumer exceptions. The language clause of the Terms of Service applies.

Annex 1: Processing details

Controller: the Customer named in the letr.dev account.
Processor: Viascom GmbH, Appenzell, Switzerland.
Subject matter and purpose: transmission of transactional email and reporting of delivery events (clause 3).
Data subjects: the Customer's users, customers, employees, contacts and other recipients and senders (clause 4.2).
Personal data: addresses, names, subjects, content, attachments, tags, headers, message IDs, delivery events, server responses, suppression entries, webhook payloads (clause 4.1). Sensitive data: only if the Customer puts it in a message; letr.dev is not designed for it.
Frequency: continuous, as the Customer sends.
Retention: content is kept, encrypted, as long as the email's metadata below. letr.dev's queue keeps it at most 3 days after the send time, and a scheduled email (up to 7 days ahead) keeps its content from the request until its send time. If the receiving mail server defers the email, the mail server's queue keeps it at most 3 more days after the hand-off. Metadata and events 30 days, purged after 32, or 365 days, purged after 367, with the message history add-on; webhook deliveries 32 days; suppression entries until removed; everything 30 days after the account ends; in backups all of this up to 52 weeks after deletion (database) or 7 days (mail server); the mail server's delivery logs, with recipient addresses, 14 days and up to 7 more days in its backups; the web server's error log at Datadog 30 days; the app server's web server logs until log rotation removes them (clauses 4.3 and 12).
Location: Germany (storage and processing); EU (encrypted database backups at Contabo); USA in transit through Cloudflare and for logs at Datadog, where the web server's error log can contain email addresses from requested URLs; Ireland and Google's data centres worldwide, including the USA, for support requests, emails to letr.dev and abuse reports in letr.dev's mailboxes at Google (clause 9).

Annex 2: Technical and organisational measures

Facts from the production setup at the time of this version.

Infrastructure and hosting

Servers at Hetzner Online GmbH in Germany, dedicated to letr.dev; Hetzner's physical security and certifications are published by Hetzner.
Cloudflare in front of the website and the API for DNS, TLS termination at the edge and protection against attacks; application ports are bound to the loopback interface and reachable only through the host's web server.
A host firewall on the mail server managed in Terraform; daily Hetzner server backups of the mail server, the last 7 kept; encrypted database backups at Contabo in the EU, full backups kept 52 weeks (clause 12.3); the app server keeps no customer data at rest apart from its web server logs (clause 4.3).

Encryption

TLS for every connection to the website, the dashboard, the API and the SMTP relay (implicit TLS on port 465, STARTTLS on 587), with Let's Encrypt certificates renewed automatically.
TLS 1.3 between the application processes and the message queue; the processes refuse to start without it.
Delivery to receiving mail servers over TLS where the receiving server offers it.
Secrets at rest (DKIM private keys, webhook signing secrets) encrypted with AES-256-GCM under a key held in the secret store. API keys stored as hashes; the plain key is shown once at creation.
Message content at rest is encrypted with AES-256-GCM under a key held in the secret store, separate from the database and its backups; the key rotates, and stored content is re-encrypted under the new key.
Credentials for the database, payment provider, sign-in provider and mail server kept in HashiCorp Vault and read by the application at startup; no secrets in the repository or in container images.

Access control

Dashboard sign-in through WorkOS (AuthKit) for customers and operators; operator functions are separate from customer functions and only available to Viascom staff. Multifactor authentication is available for operator accounts.
Server access by personal SSH keys only; the Ansible roles define the server state.
Each API key carries a permission (sending, read only or full access) and belongs to one account; webhooks are signed and delivered with mutual TLS from a letr.dev client certificate authority.

Data minimisation and retention

Message content is kept with the email's metadata for the same period and deleted with it by the same scheduled job. letr.dev's queue keeps it at most 3 days after the send time, and a scheduled email (up to 7 days ahead) keeps its content from the request until its send time. If the receiving mail server defers the email, the mail server's queue keeps it at most 3 more days after the hand-off.
Metadata and delivery events are kept 30 days and purged after 32 by a scheduled job, or 365 days and purged after 367 with the message history add-on; webhook deliveries 32 days.
Backups keep content and metadata for up to 52 weeks after deletion (database) or 7 days (mail server) (clause 12.3).
Application logs carry IDs and counts, never recipient addresses. The mail server's operational log leaves the server only with every email address masked, and a deployment check fails if a sample address survives the masks.
The mail server's delivery logs name the recipients; they stay on the mail server, a scheduled job deletes them after 14 days, and its backups keep them up to 7 days longer. The web server's error log, which can contain email addresses from requested URLs, is kept 30 days at Datadog.
No open or click tracking; no analytics or cookies on the website.
An account is deleted 30 days after it ends, with every record keyed to it, by a daily scheduled job; a test fails if a new table is added without the cascade.
Recipient erasure on request through DELETE /v1/recipients/{email}.

Separation and integrity

Every record is keyed to one account; API keys and sign-ins only reach their own account's data.
Per-account suppression lists, bounce and complaint rates and limits.
Every operator action on an account (pause, resume, decline, step changes, revoked keys, cancelled queue, evidence export) is recorded in the account history in the same transaction as the action.

Availability

Public monitoring of the API and the sending pipeline at status.letr.dev every 5 minutes, including an end-to-end test email to an external mailbox.
Server and process monitoring through Datadog; incidents announced on the status page.

Organisation

Written runbook for review of new accounts, abuse handling, account takeover, authority requests, delisting and data breaches, kept in the infrastructure repository.
Every abuse or takeover case is recorded in the account history; an exported evidence file is kept in one access-restricted, encrypted place and deleted when the case is closed.
Breach handling: detect and record, assess, inform affected customers without undue delay, for data for which Viascom is the controller, report to the FDPIC where the risk is high, for the Customer's data clause 11 applies, document every breach for at least 2 years.
Sub-processors bound by contract; changes announced 30 days ahead.
Nikola Stankovic is responsible for data protection at Viascom; no data protection officer is appointed.

Annex 3: Sub-processors

Taken from letr.dev/subprocessors at the time of this version; the page is the authoritative current list.

Sub-processor	Purpose	Location	Data	Transfer basis
Hetzner Online GmbH	Hosting of the website, the API, the database and the mail servers	Germany	Account and billing details, sending domains and API keys, the emails customers send and their delivery events, suppression lists, server logs	None needed (EU; adequate under Swiss law)
Cloudflare, Inc.	DNS, content delivery and protection against attacks for the website and the API	USA	IP addresses and connection data of visitors, API requests in transit including recipients and content of emails	EU-US and Swiss-US Data Privacy Framework
Contabo GmbH	Storage of encrypted database backups	EU	Encrypted backups of the database: account and billing details, sending domains and API keys, the emails customers send and their delivery events, suppression lists	None needed (EU; adequate under Swiss law)
WorkOS, Inc.	Sign-in to the dashboard	USA	Email address, name, sign-in credentials, IP address and browser of each sign-in	Standard contractual clauses with the amendments for Switzerland
Datadog, Inc.	Monitoring of the servers, the web server and the mail server software	USA	Server health and process metrics; the web server's error log (client IP addresses and requested URLs, which can contain email addresses); the mail server's operational log with email addresses masked	EU-US and Swiss-US Data Privacy Framework
Google Cloud EMEA Limited	Google Workspace: letr.dev's mailboxes, including the one that receives support requests	Ireland; Google's data centres worldwide, including the USA	Emails to letr.dev addresses, support requests and abuse reports about the Customer's emails: sender's email address, account name and ID, and the message, which can contain recipient addresses, email headers or email content	EU-US and Swiss-US Data Privacy Framework (Google LLC) for the USA; for other countries, the standard contractual clauses in Google's Cloud Data Processing Addendum

WorkOS processes data for which Viascom is the controller (sign-in); it does not process the Customer's email and is listed for completeness. Google holds letr.dev's mailboxes. For support requests and other emails to letr.dev, Viascom is the controller; Google acts as a sub-processor for the Customer's personal data only where such an email or an abuse report about the Customer's emails contains it, such as recipient addresses and copies or headers of those emails. Stripe, a separate controller of the payment and order data, and Sold through Link, LLC, the merchant of record, are not sub-processors and do not process the Customer's email.

Viascom GmbH, Appenzell, 02.11.2026