Ch 05 · Operating manual
Privacy Policy
Last updated · 30 September 2026
We store what the Service needs to work: your account, your recipients, and a record of what was sent to whom. Platform credentials are encrypted before storage, and every workspace is isolated from every other at the database level.
We do not sell data, do not train models on it, and run no advertising trackers or third-party analytics; our own website analytics are cookieless and store no IP addresses. Cookies are limited to keeping you signed in and protecting the Slack install flow.
For the people you message, you are the controller and we act on your instructions — which is why consent is recorded per recipient and checked again at send time.
This summary is for orientation only. The numbered sections below are the terms that apply.
§ 01Who this covers
This policy explains how DanixSoft(“we”, “us”) handles personal data in connection with BulkReach(the “Service”). It covers two different groups of people, and the distinction matters:
- Customers — the people who sign up and use the dashboard. For their account data we are the data controller.
- Recipients — the people a customer sends messages to. For that data the customer is the controller and we are a processor acting on their instructions. If you received a message and want it to stop, contact the organisation that sent it; we can put you in touch if you write to us.
§ 02What we store
Account data. Your email address, name, avatar URL if you sign in with Google, your role, and the workspace you belong to. Authentication is handled by Supabase Auth; we never see or store your password in readable form.
Workspace data. The workspace name, its timezone, and a URL-safe slug.
Recipient records. For each recipient a customer adds: display name, and — depending on source — email address, phone number, avatar URL, Slack user ID, tags, and whether consent to be messaged has been recorded.
Message and delivery data. The text of each campaign, the channels it targeted, the exact personalised text delivered to each recipient, the delivery status (sent, failed, pending or skipped), any provider error, and timestamps.
Platform credentials. Slack bot tokens and WhatsApp session credentials. Both are encrypted with AES-256-GCM before storage. The Slack token column is additionally revoked from client database roles so it is only ever readable by our server processes.
Operational data. Rate-limit counters, usage totals, and application logs. Logs are configured to redact session material, credentials and authorisation headers.
What we do not store. We do not store your Slack or WhatsApp password. We do not read your Slack channels — the Service requests only the scopes needed to list members and send direct messages. We do not download or retain your WhatsApp message history; full history sync is deliberately disabled.
§ 03Why we process it, and on what basis
- To provide the Service — authenticating you, storing recipients, queueing and delivering messages, and recording what happened. Legal basis: performance of a contract.
- To keep the Service secure and working — rate limiting, abuse prevention, error diagnosis. Legal basis: legitimate interests.
- To bill you — usage counts against plan allowances. Legal basis: performance of a contract and legal obligation.
- To contact you about the Service — security notices, material changes to these policies. Legal basis: legitimate interests or legal obligation.
We do not sell personal data. We do not use customer or recipient data to train machine-learning models. We do not use recipient data for our own marketing.
§ 04How your data is kept separate
Every table in our database carries a workspace identifier and is protected by Postgres Row Level Security. Policies are written so that a query can only ever return rows belonging to the requesting user’s own workspace — enforcement sits in the database, not in application code, so an application bug cannot leak across customers.
Three server-side processes necessarily run with elevated database privileges: the send dispatcher, the platform OAuth callback, and the WhatsApp sending service. Each scopes every query by workspace explicitly, and the schema ships with an audit script that flags any table left unprotected.
§ 05Who else is involved
We use a small number of sub-processors to run the Service:
- Supabase — database, authentication and storage.
- Vercel — hosting for the dashboard and API.
- Render — hosting for the persistent WhatsApp sending service.
- Slack Technologies — where messages are delivered, when you use Slack.
- Meta Platforms (WhatsApp) — where messages are delivered, when you use WhatsApp.
Each is bound by its own agreement to process data only as needed to provide its service. Where data is transferred outside the UK or EEA, transfers rely on Standard Contractual Clauses or an equivalent safeguard. We will give notice before adding a sub-processor that materially changes how your data is handled.
We may also disclose data where required by law, to enforce our Terms, or to protect the rights and safety of our customers and message recipients.
§ 06Security
Measures we take include:
- encryption in transit (TLS) and encryption at rest for platform credentials;
- AES-256-GCM with authenticated encryption for Slack tokens and WhatsApp session data, so tampered ciphertext is rejected rather than silently accepted;
- row-level database isolation between workspaces, with a repeatable audit;
- column-level revocation of the most sensitive fields from client roles;
- per-workspace rate limits on sending, importing and connecting;
- log redaction for credentials and session material.
No system is perfectly secure. If we become aware of a breach affecting your personal data, we will notify you and any relevant supervisory authority as required by law and without undue delay.
§ 07How long we keep it
- Account and workspace data — for as long as your account exists, then deleted within 30 days of workspace deletion.
- Recipient records — until you delete them, or until the workspace is deleted. Disconnecting a channel removes the recipients that came from it.
- Delivery history — for the period stated on your plan, after which it is deleted. Export it first if you need to keep it.
- Platform credentials — until you disconnect the channel, at which point they are deleted immediately.
- Rate-limit counters — pruned automatically after 24 hours.
- Billing records — retained as long as required by tax and accounting law, typically six to seven years.
§ 08Your rights
Depending on where you live, you may have the right to access, correct, delete, restrict or object to our processing of your personal data, to receive it in a portable format, and to withdraw consent where processing relies on it. You also have the right to complain to your local data protection authority.
To exercise any of these, write to privacy@danixsoft.com. We respond within 30 days. Much of it you can do yourself: account details are editable in settings, recipients can be deleted from the recipients screen, and deleting a workspace removes its data.
If you received a message sent through BulkReach and want to be removed, contact the organisation that sent it — they control that list. If you cannot reach them, write to us and we will pass the request on.
§ 09Website analytics
To see how BulkReach is used, we run DanixSoft’s own first-party, cookieless analytics. It is hosted by DanixSoft at admin.danixsoft.com and the data is stored in DanixSoft’s own database; no third-party analytics or advertising service is involved. It records:
- pages visited (ids and private codes in page addresses are masked);
- the referring website and any UTM campaign tags in the link;
- approximate location (country, region and city), derived from the IP address by our hosting provider;
- browser, operating system and device type;
- clicks on links and buttons (in the dashboard the button or link text is not recorded);
- time on page and scroll depth;
- page-load speed measurements (Core Web Vitals), which are timing numbers only;
- conversion events, such as a sign-up or a sent broadcast, recorded without personal details.
It does not use cookies or local storage, and it does not store IP addresses. Unique visitors are counted with a salted hash that rotates daily; the salt is deleted after a day, so the hash cannot be reversed or linked across days. This data is not sold or shared with advertisers.
§ 11Children
The Service is not directed at children and is not intended for anyone under 18. We do not knowingly collect personal data from children. If you believe a child has provided us with personal data, write to privacy@danixsoft.com and we will delete it.
§ 12Changes to this policy
We may update this policy as the Service evolves. The “last updated” date above always reflects the current version, and we will give notice by email or in the product before material changes take effect. Continued use after that point means you accept the updated policy. Questions: privacy@danixsoft.com.