Privacy

Who is who

A customer's contacts belong to that customer. They decide who is in the list and why; we hold the records to do a job they asked for. In the usual vocabulary, the customer is the controller of their contact data and this service is the processor. For the customer's own account -- the login, the organisation, the billing record -- we are the controller.

If a recipient asks about their data, the answer belongs to the customer who holds the relationship. We act on that customer's instruction.

What is held

• Account records. The email address, optional name, role and organisation of each user. Passwords are stored as a hash and nothing else -- the API has no path that returns one.
• Contacts the customer imports. Whatever fields they choose to put in, including fields they add to the schema themselves.
• Consent records. One row per decision: the contact, the consent group, the state, when it changed, the source, which sending identity they were reacting to, which send it came from, and the IP address and user agent seen at the time. These exist so that a claim to have had permission can be evidenced, which is a reason to keep them rather than a reason to collect more.
• Sending and delivery events. What was sent, to whom, and what the receiving server said about it, including bounces and complaints.
• Relay and CRM credentials. Encrypted at rest and masked on every read path. The API never returns a credential value, not even truncated. Anything we only need to check rather than replay -- a password, a webhook signature -- is hashed instead, so we could not replay it.
• Support tickets. The address, name and message given on the help page, plus the IP address and user agent of the submission, which are kept to deal with abuse of the form.

Cookies on this website

One: the session cookie, set after you sign in, HttpOnly and signed so the browser cannot read or forge it. There are no analytics cookies, no advertising cookies and no third-party scripts on these pages.

The open and click tracking in a campaign is a different thing entirely: it belongs to the customer sending that campaign, is switched on per send, and is governed by that customer's own notice to their recipients.

Who else sees it

• The relay you connect. You choose it and you hold the account. Messages go through it, so it sees them.
• A CRM you connect. Only the fields the sync is configured to move, in the direction it is configured to move them.
• The payment processor for a paid plan. Card details are handled by it and never reach this service.
• Platform staff. Support access is possible and it is audited -- every administrative write records the row before and after, in a separate append-only database, so an override reads back as a diff and not as a claim.

Keeping and deleting

Suspension stops an organisation using the product. It does not delete their records, and a lapsed subscription drops the account to the free plan rather than locking it: the data is theirs, and a customer who cannot log in cannot pay.

Every list page exports what it is showing to CSV, on every plan -- the rows on screen, in the columns that list shows. There is no whole-account export and no self-service "delete my organisation" button in the product today; for either, including a full extract of an organisation's records, raise a ticket.

Changes to this policy

This policy may change at any time, and the version published here is the one that applies. The date at the top is the date it last changed, so a change is visible rather than silent, and the terms may change on the same footing.

Where a change materially widens what is collected, what it is used for, or who else sees it, we intend to tell account owners directly rather than rely on the date being noticed. That is how we mean to behave; the binding notice period is in the outstanding list below and has not been agreed yet, so it should not be relied on as one.