- Legal
- Data processing agreement
Legal
Data processing agreement
Our Article 28 commitments as your processor, including transfers and retention.
Drafted in-house and not reviewed by a lawyer. It is accurate about what the system does; it is not legal advice, and it has not been through external legal review.
Last reviewed 2026-09-14.
This agreement is between FLOWXO LLC (“WhooshBang”, “we”) and the organisation that has agreed to our terms of service (“you”). It forms part of those terms and takes effect with them. Where it conflicts with them, this agreement governs for the processing of personal data.
Notices under this agreement, and any request under clause 9, go to privacy@flowxo.com, attention Nathan Stults.
It is written to satisfy Article 28 of the UK and EU General Data Protection Regulation.
1. Who is controller and who is processor
This is the clause your lawyer reads first, because it decides who answers a person who comes asking.
We are the processor and you are the controller for everything about the people you send notifications to. You decide who they are, what they are told and when; we carry it. That covers:
| Category | What it is |
|---|---|
| Recipient identity and routing | The identifier you supply for a person, their email address or other provider routing identity, their channel binding, subscription links, sessions, group memberships and machine clients |
| Notification content and answers | The text you send, any prompt and options, any answer a recipient types, notification images, and the event payloads we send to your endpoint |
| Delivery diagnostics | Delivery attempts, message delivery metadata and provider callbacks |
We are the controller for your own account: your members’ sign-in identity, your credentials and authorizations, our audit trail, our abuse controls and our usage metering. You are not our processor for any of it. What we do with it is in our privacy statement.
We are also a controller, separately from you and for two named purposes only, over recipient data. They are enumerated in clause 12, they are narrow, and adding a third is a decision we would record before building it.
1.1 Where the sending identity is ours, the picture is less clean, and we say
so rather than wait to be asked. Under whooshbang_shared on Telegram and
whooshbang_hosted on Slack, and whooshbang_shared on email, we supply the
whole consent mechanism: a bot, app or email domain we own, default consent
wording that names WhooshBang, an origin we operate
that your recipient’s browser reaches directly, and a withdrawal control you
cannot rewrite. We consider ourselves your processor in those modes too, because
our purposes do not converge with yours — we take nothing from the data itself
and supply the mechanism only to perform this agreement.
We recognise that a regulator could see it differently and treat us as a joint
controller with you under Article 26 for the consent step alone. If that
happens, we will agree an Article 26 arrangement with you covering those modes,
at our cost, and it will not change how notifications are delivered.
Where the sending identity is yours — customer_byok and customer_managed
on Telegram, customer_managed on Slack, and customer_managed email through
your Resend team — this paragraph does not arise at all, because you own the
identity your recipient sees and the consent runs to you.
2. What we process, and for how long
Subject matter and purpose. Delivering the notifications you send to the people you nominate, over the channels you choose, and telling you what happened.
Duration. For as long as your account is open, plus the retention windows in clause 8.
Categories of data subject. The people you choose to notify, and the members of your own organisation who use WhooshBang.
Types of personal data. Whatever you put in a notification; the identifier you supply for a person; the email address or other routing identity that reaches them at their chosen channel; a recipient’s locale and, if you supply one, their time zone; their consent record; and any answer they type back.
What we ask for depends on the channel. Email delivery requires one recipient email address. We do not require a recipient’s name or phone number, and non-email channels do not require an email address.
3. Our instructions come from you
3.1 We process personal data only on your documented instructions, which are these terms, your configuration, and the API calls you make. Using the service is the instruction.
3.2 If we believe an instruction breaks data protection law, we will tell you.
3.3 We will not process personal data for our own purposes, except the two in clause 12.
3.4 If we are required by law to process personal data otherwise, we will tell you first unless the law forbids it.
4. Confidentiality
Everyone we authorise to process personal data is bound by an obligation of confidentiality, and access is limited to those who need it to run the service.
5. Security
We implement the measures in Annex A, which are the ones actually in the product rather than a list of intentions. We will not weaken them below what Article 32 requires.
6. Subprocessors
6.1 You give us general written authorisation to engage subprocessors. The current list, with what each one does and where, is here.
6.2 We will publish an addition or replacement at least thirty days before that subprocessor begins processing. You may object within ten days on reasonable data protection grounds; we will work with you in good faith, and if we cannot resolve it you may terminate the affected service.
6.3 Every subprocessor is bound by written data protection obligations no less protective than those in this agreement, and we remain liable to you for what they do.
6.4 Telegram and Slack are not ordinary subprocessors, and clause 7 says why.
7. International transfers
7.1 Everything WhooshBang itself stores comes to rest in the European
Union. Your data and your recipients’ data in WhooshBang are stored in a
PostgreSQL database in Ireland
(aws:eu-west-1), and the servers that read it run there too.
The qualifier is load-bearing and we would rather state it than have it found. Data at rest is in the EU; two things transit infrastructure with no stated jurisdiction on the way there. A recipient’s typed answer, and on Slack their workspace identity, pass through Cloudflare Queues, for which Cloudflare documents no region option. And authorization records for your own signed-in users are stored in Cloudflare’s globally replicated key-value store — clause 7.2 and our privacy statement say what is in it and why we left it that way. Email sent through Resend is also stored by Resend in the United States as clause 7.5 describes.
7.2 Where a transfer outside the EEA does happen, the basis differs by subprocessor and we state each one rather than giving a single blanket clause:
| Subprocessor | Basis |
|---|---|
| Tiger Data | No transfer of stored data out of the EEA. Where its US company processes it, the EU standard contractual clauses (Decision 2021/914) and the UK Addendum apply under its published addendum |
| Cloudflare | The EU-U.S. Data Privacy Framework, with the standard contractual clauses in Cloudflare’s addendum taking over automatically if that certification lapses — Cloudflare has undertaken to notify us if it does |
| Clerk | The EU-U.S. Data Privacy Framework, with the standard contractual clauses in its addendum as a standing fallback |
| Resend | The EU-U.S. Data Privacy Framework and the EU standard contractual clauses incorporated into Resend’s DPA. A customer-owned Resend team’s transfer terms sit in the customer’s own Resend agreement |
| Slack | Where your workspace is established outside the US and Canada, the receiving Slack entity is Slack Technologies Limited in Ireland, and the onward leg to Slack’s US company is covered by Slack’s own standard contractual clauses and by the EU-U.S. Data Privacy Framework |
| Telegram | Telegram publishes no transfer instrument available to a bot operator. Clause 7.3 |
7.3 Telegram, stated plainly. Delivering a notification into a person’s own Telegram conversation is a communication to them at an address they chose, not an onward transfer of their data to a third party we picked: they held that account before you invited them, and Telegram is an independent controller of its own user, which is what Telegram’s own privacy policy calls itself. Telegram states that data for an account signed up from the UK or EEA is stored in data centres in the Netherlands. What is genuinely ours is narrower — the routing identity we create so a message can reach that person, and disclosing it to Telegram in order to deliver. Telegram offers no adequacy decision and no standard contractual clauses a bot operator can enter into, so we do not claim one.
7.4 Slack, stated plainly. What a notification becomes once delivered is Customer Data inside your own Slack workspace, held by Slack as your processor under your own Slack agreement — Slack’s privacy policy says “In general, Customer is the controller of Customer Data” and “In general, Slack is the processor of Customer Data”. We are not a party to that agreement. Where your workspace is established outside the US and Canada the receiving entity is Slack Technologies Limited in Ireland, so the disclosure we make does not leave the EEA; the onward leg to Slack’s US company is Slack’s own to cover, and it does, with the standard contractual clauses its privacy policy leads with and the Data Privacy Framework above them.
7.5 Resend, stated plainly. Sending an email gives Resend the recipient address, message content and delivery metadata. Resend states that all customer data is stored in the United States even when a sending region is selected. The shared WhooshBang pool uses Resend as our subprocessor under Resend’s DPA. A customer-owned connection instead uses the customer’s Resend team under the customer’s agreement. Resend states that Free, Pro and Scale email and log data is retained for 30 days and Enterprise retention can be configured. Its paid no-content-storage control is enabled by support only for eligible teams; it is not a standard WhooshBang control. See Resend’s GDPR statement and content-storage requirements.
7.6 If you would rather not rely on clause 7.3, WhooshBang supports channel
connections where the bot or app is yours — customer_byok and
customer_managed on Telegram, customer_managed on Slack. In those modes you
have chosen the provider and hold the credential, and the provider relationship
is yours.
8. Retention and deletion
8.1 Content is deliberately short-lived. The fact that something happened outlives what it said.
| What | Kept for |
|---|---|
| Notification content | 7 days, then the stored ciphertext is removed and the message record survives without it |
| Email content, recipient address, delivery events and logs copied to Resend | 30 days on Resend Free, Pro and Scale plans; configurable on Enterprise. This provider copy is separate from WhooshBang’s 7-day content window |
| A recipient’s answer | The same window; that they answered survives the answer |
| Event payloads sent to your endpoint, and the machine-event envelopes that carry the same answer | 7 days |
| Event metadata | 90 days |
| Audit events | 365 days |
| A subscriber’s identifier, locale and time zone | While that subscriber exists |
| Structured log lines at Cloudflare, which carry identifiers rather than names or content | 7 days, set by Cloudflare’s plan rather than by us |
8.2 You cannot currently shorten these windows. They are the same for every customer. We say so rather than imply a control that does not exist; making the content window a project’s to choose is planned.
8.3 On termination, we will delete or return personal data at your choice, except where law requires us to keep it.
We would rather be exact about what stands behind that than let it read like a built capability. There is no deletion operation in the product today — not a self-service control and not an internal tool. A deletion or return on termination would be carried out by an operator working directly against the database. The obligation is ours and we will meet it; building the operation that ought to serve it is in progress, and this clause will be narrowed to describe it once it exists.
9. Helping you answer your users
9.1 Taking into account the nature of the processing, we will assist you in responding to a request from one of your recipients to access, correct, delete, port, restrict or object.
9.2 What that assistance is today, precisely, because a promise of assistance we have not built would be worse than no promise at all.
- Access and portability. A recipient’s data is identifiable from their binding, and we will assemble a copy and return it to you. This is done by our staff querying the database on your written request, not through an API or a dashboard control.
- Erasure. No deletion operation exists in the product. We will act on your instruction, by hand, in the same way. We are not describing a tested process, and we say so.
- Ending consent is different, and it does work. A recipient can withdraw consent themselves at any time; that invalidates their binding and a later send finds nothing to send to. That is a built, self-service path and it is the one most requests actually want.
Building the first two into operations is in progress, and this clause will be narrowed to describe them once they exist.
9.3 If a recipient contacts us directly, we will not answer them on your behalf. We will tell them to contact you, and tell you that they asked.
10. Helping you meet your other obligations
We will assist you, at your cost where the effort is more than trivial, with security of processing, breach notification, data protection impact assessments and prior consultation, so far as the information is ours to give.
11. Breach notification
We will tell you without undue delay after becoming aware of a personal data breach affecting your data, with what we know: what happened, which categories and roughly how many people, the likely consequences, and what we are doing about it.
12. The two purposes we determine ourselves
Article 28(10) says a processor that decides its own purposes for the same data is a controller for those purposes. Two apply to us, and naming them is better than a promise that reads well and is false.
12.1 The consent record. Every activation, pause, resume and revocation of a recipient’s consent is written to our audit trail and kept for 365 days. No customer instructs it; we keep it so that whether somebody agreed to be messaged can be answered later. Our basis is Article 6(1)(f).
12.2 The shared-bot management list. Where a recipient reaches our shared Telegram bot and asks to manage their notifications, the list they see today spans every sender who reached them through that bot. Nobody instructed the aggregation. Our basis is that person’s interest in one working control over a bot they are talking to, Article 6(1)(f). We are narrowing this list to a single sender, and this clause goes away when we do.
12.3 Neither purpose reads the content of a notification, neither is commercial, and neither touches who is messaged or what is said. There is no third, and adding one would be recorded here first.
12.4 Being a controller for those two purposes means we owe your recipients a notice directly, and we do not yet give one. Articles 13 and 14 require the controller of a purpose to tell the data subject about it, and that duty runs from us to your recipient rather than through you. This agreement is addressed to you; your recipient never sees it. Writing a recipient-facing notice that discloses the consent record and the shared-bot list, and putting it where somebody who pressed Start in a Telegram chat can reach it, is work in progress. Until it exists this is a gap on our side, not yours, and we would rather name it here than have you discover it.
13. Audit
13.1 We will make available the information needed to show we meet this agreement, and contribute to an audit or inspection you conduct or mandate.
13.2 In practice this means answering a written security questionnaire and providing supporting documentation, within thirty days of your written request and no more than once in any twelve months unless a personal data breach or a supervisory authority’s instruction gives you cause. We bear our own costs for one such review a year; beyond that, or for a review you ask a third party to conduct, you bear the reasonable cost of our time.
13.3 We do not currently hold an independent security certification of our own, and we do not claim one. Our subprocessors hold their own — the certification column in the subprocessor list says which — and we will pass on any report we are entitled to share.
14. Liability and precedence
This agreement is subject to the limitations of liability in our terms of service. Clause 12 there is a single aggregate cap that covers our breach of this agreement, including the liability we accept under clause 6.3 for our subprocessors, and it is low. Clause 12.4 invites you to agree a higher limit with us if you need one, and clause 12.5 records what no contract between us can limit in any case. Where those terms and this agreement conflict on the processing of personal data, this agreement governs.
Annex A — Technical and organisational measures
These are measures in the product today, not intentions.
Content is sealed from our own database. Notification content, a recipient’s Telegram identity, an email recipient’s address, your bot tokens, your endpoint signing secrets and notification images are encrypted with AES-GCM under a key our servers hold and the database never sees. Anyone reading the database directly — an operator query, a support tool, a leaked credential, a backup file — gets ciphertext. Provider routing identities also have one-way lookup digests so a binding can be found without the identity being readable.
Not everything is sealed, and here is what is not. A recipient’s typed answer, and the identifier you supply for a person, are stored in readable form. That identifier is yours, and if you make it an email address then an email address is what the database holds — so use an opaque identifier if you would rather it were not. Sealing the answer is planned.
Transport is encrypted everywhere. Database connections are refused unless
they are sslmode=verify-full against a pinned certificate authority. All
external calls are over TLS.
Volumes are encrypted at rest by our providers. Tiger Data documents that “Your data on Tiger Cloud is encrypted both in transit and at rest. Both active databases and backups are encrypted”, using AES-256 with keys held in AWS Key Management Service and “never stored in plaintext” (Tiger Cloud security). Cloudflare documents that “All values stored in KV are encrypted at rest”, under AES-256-GCM (KV data security). Volume encryption defends against a stolen disk; it is the sealing above that defends against a query.
Addresses are not stored. A caller’s network address is hashed before it is used for rate limiting, and only the fingerprint is kept. Every stored fingerprint in the API carries a secret pepper, so it cannot be reversed by guessing addresses. One rate-limiter key at the edge — the one guarding the authorization endpoint — is hashed without that pepper, which for an IPv4 address is reversible by anyone holding the key; it is a transient key rather than a stored row, and it is being changed.
Tenant isolation. Every query for tenant data is scoped to one organization and project. A credential names its own scope and cannot widen it.
Access control. Credentials are stored as digests, are revocable, and expire. Every credential creation, use and revocation is audited.
Compute placement. Production compute is pinned to aws:eu-west-1, the same
jurisdiction as the database it reads.
Resilience. Delivery is asynchronous and retried, with a dead-letter queue for jobs that keep failing, so a provider outage delays a notification rather than losing it.