Privacy statement

Drafted in-house and not reviewed by a lawyer. It is accurate about what the system does; it is not legal advice.

Last reviewed 2026-09-14.

WhooshBang is operated by FLOWXO LLC. Contact us about anything on this page — including any request under the “Your rights” section below — at privacy@flowxo.com, attention Nathan Stults.

​

There are two kinds of person in this document

Keeping them apart is the whole of it, because the answers differ.

You, our customer, and the people at your organisation who sign in and use WhooshBang. We decide why and how your data is processed, so for you we are the controller and you exercise your rights against us directly.

Your recipients — the people you send notifications to. You decide who they are, what they are told and when. For them you are the controller and we are your processor, so a recipient who asks us for their data is asked to take it up with you, and we help you answer. Our data processing agreement sets out that help.

Two narrow exceptions are named at the end, where we do decide something for ourselves about a recipient.

​

What we hold about you, and why

What	Why we hold it	Our lawful basis
Your sign-in identity — email address, name, authentication factors, held at Clerk	So you can sign in, and so we know who did what in your organization	Performance of our contract with you, Article 6(1)(b)
Your organization and project membership — an organization identifier, a user identifier, a role	So an organization can have more than one person in it, with different permissions	Performance of our contract, Article 6(1)(b)
Your credentials and authorizations — API keys, machine credentials, OAuth grants and the consent you gave to a client	So your tools can act for you, and so you can revoke them	Performance of our contract, Article 6(1)(b)
Your audit trail — who created, changed or revoked what, kept for 365 days	Our own accountability. No customer asks us for it; we keep it because we should be able to answer what happened	Our legitimate interests, Article 6(1)(f) — operating a service we can account for
Abuse and rate-limiting records — a one-way fingerprint of the network address a request came from, rather than the address	So a flood of failed sign-ins cannot be used against you or us	Our legitimate interests, Article 6(1)(f) — security of the service
Usage counts — accepted sends per organization, project, environment and day	Billing and capacity. These name no recipient at all	Performance of our contract, Article 6(1)(b)

We do not profile you, we do not sell your data, and we do not use it to train anything.

​

What we hold about your recipients

We hold it for you, on your instructions. In outline: the identifier you supply for that person, the routing identity that lets a message reach them, their consent record, the notifications you send and any answers they give, plus delivery diagnostics. What each item is, how long it lives and what we will do when you ask is in the data processing agreement.

Two things are worth saying here rather than only there.

The content of a notification is sealed from our own database. Message content, a recipient’s Telegram identity, an email recipient’s address, your bot tokens and your endpoint signing secrets are encrypted with a key our servers hold and the database never sees. Anyone reading the database directly — including us — gets ciphertext.

Content is short-lived by design. A notification’s text is removed after seven days and the record of the send survives without it. The fact that something happened outlives what it said.

​

Where your data is

Everything WhooshBang itself stores comes to rest in the European Union, in a PostgreSQL database in Ireland (aws:eu-west-1), and the servers that read it run in the same place. There is one database, for every customer, in every region; you do not choose, because one answer is worth more than a fast one.

That sentence is about where data is stored. On the way there, a recipient’s typed answer — and on Slack their workspace identity — passes through Cloudflare’s queues, for which Cloudflare states no region. We would rather say that than let “rests in the EU” do work it cannot do.

Three qualifications, stated because they are true rather than because anyone asked:

• Sign-in identity is held at Clerk in the United States, covered by the EU-U.S. Data Privacy Framework with standard contractual clauses underneath.
• Authorization records replicate globally, and we chose that. OAuth grants and consent state live in Cloudflare’s key-value storage, which replicates across Cloudflare’s network. Cloudflare does offer a European-only option, and we considered it: what is stored is an organization identifier, a member identifier, the scopes granted and the client’s name — no names, no content, and nothing about your recipients — and the sign-in identity those identifiers point at is already held at Clerk in the United States. We judged confining the pointer disproportionate to the migration it would require. We will revisit it if what we store there ever changes.
• A delivered notification comes to rest with the messenger your recipient chose. That is Telegram’s or Slack’s, under their own terms — see our subprocessor list.
• Resend stores the email copy it processes in the United States. Sending email gives Resend the recipient address, message content and delivery metadata. Resend states that this data is stored in the United States even when a sending region is selected. On its Free, Pro and Scale plans it retains email and log data for 30 days; Enterprise retention can be configured. Disabling message-content storage is a paid, support-enabled control with eligibility requirements, not a normal WhooshBang onboarding setting. See Resend’s GDPR statement and content-storage requirements.

​

Who else processes it

Six companies, each named with what it does and where: our subprocessor list. We will publish an addition there at least thirty days before it starts.

​

How long we keep it

What	Kept for
Notification content, and a recipient’s answer	7 days, then removed; the record that a message was sent survives
Email content, recipient address, delivery events and logs copied to Resend	30 days on Resend Free, Pro and Scale plans; configurable on Enterprise. This is separate from WhooshBang’s 7-day content window
Event payloads we send to your endpoint, and the machine-event envelopes that carry the same answer	7 days
Event metadata	90 days
Audit events	365 days
Structured log lines at Cloudflare, which carry identifiers rather than names or content	7 days, set by Cloudflare’s plan rather than by us
Your organization, project and membership records	While your account is open

​

Your rights

You can ask us to give you a copy of what we hold about you, correct it, delete it, restrict or object to how we use it, or give it to you in a portable form. Where we rely on legitimate interests, you can object and we will stop unless we have compelling grounds.

Ask us at the address at the top of this page. We will answer within one month.

Two things about how, because a right you cannot exercise is not a right:

• Access and export work today, by hand. Someone here queries the database and sends you what we hold. There is no button.
• There is no deletion operation in the product at all — not a button and not an internal tool. We will act on a deletion request, by an operator working directly against the database. We are telling you that rather than describing a process we have not built, and building it is in progress.

You can also complain to a supervisory authority in the EU or UK country where you live or work.

​

The two things we decide about a recipient

Almost everything we do with a recipient’s data, we do because you told us to. Two things we decide ourselves, so for those two we are a controller in our own right and we say so rather than let it pass:

• We keep a 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 asks for it; we keep it so that whether somebody agreed to be messaged can be answered later. Our basis is our legitimate interest in being able to account for that, Article 6(1)(f).
• Our shared Telegram bot shows a person the notifications they receive through it. Where a recipient reaches our shared bot and asks to manage their notifications, the list they see today spans every sender who reached them through that bot. Nobody instructed that; our basis is that person’s own 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.

Those two are the whole list. Adding a third is a decision we would take deliberately and record here before building it.

​

Changes

We will update this page when what we do changes, and the date at the top says when it was last reviewed.