What we hold, and what we do with it.

This policy covers the Sendbu service at sendbu.com, operated by [LEGAL ENTITY NAME — fill in], registered at [REGISTERED ADDRESS — fill in].

You are our customer; the people you message are not. The messages you send through us are yours, and this page describes how we hold them on your behalf.

What we hold

All of it, table by table:

• Your account. Your email address, a display name if you gave one, when the address was verified, an avatar URL if your identity provider supplied one, and — only if you set a password — a hash of it. We never store the password itself.
• How you sign in. If you use Google or GitHub, the link between your account and that provider's identifier for you. If you use a sign-in link, a short-lived token record. Your active sessions.
• Your organization and its members. Its name, its plan, who belongs to it and in what role, and invitations sent to addresses that have not joined yet.
• Your WhatsApp session credential — encrypted. Pairing a number produces a credential that keeps the session alive. It is sealed with a key held by the application and stored only in that sealed form.
• The messages you send. The body text, the recipient's phone number, the channel, the status, the provider's id for it, your idempotency key, and a failure code and reason if it failed. We hold message bodies. We do not scan, analyse, sell, or train anything on them.
• Your channels. Which provider, the connection status, the paired phone number, and what that channel can do.
• Your API keys — hashed. A short non-secret prefix so we can find the key, a hash of the secret, a name, and when it was last used and revoked. The secret is shown once at creation and never stored in a form we could give back to you.
• Your webhook endpoints. The URL, which events it subscribes to, and its signing secret — encrypted, because we need it to sign with. Plus a delivery log: which event, the payload we sent, the response code, and the retry schedule.
• Usage counts. Messages sent and channel-days, per month, per organization.
• Operator actions. When someone on our side suspends, restores, or otherwise acts on an account, we record that it happened, to which account, and by whom. No message body or phone number is recorded in that log.

We do not run analytics or advertising trackers on this site, and we set no cookie other than the one that keeps you signed in.

How long we keep it

Indefinitely, with one exception, and we would rather name the exception than round it off in either direction. There is no job that expires old messages, no sweep that clears consumed sign-in tokens and no archival tier. What we hold, we hold until something removes it.

Three things remove it:

• The webhook delivery log ages out after 30 days. Every attempt we make to call your endpoint is recorded — the status we got back, and the response body if it failed — and a settled record older than 30 days is deleted automatically, in hourly passes. A delivery still waiting to be retried is never removed by age, and nor is one that was queued and whose attempt never ran: those are kept because they are evidence of a bug worth finding. This is the only scheduled deletion in the service.
• You delete it. Deleting a channel takes its message history with it. Deleting a webhook endpoint takes its delivery log.
• You ask us to close the account. An operator suspends it and then purges it, which deletes the organization and — by database cascade — its members, channels, credentials, messages, API keys, webhook endpoints, delivery log and usage counts.

Write to [PRIVACY CONTACT ADDRESS — fill in] to ask for a copy of your data or for it to be erased.

Who can see it

• You and the members of your organization. Every read the API and the panel make is bound to the organization your key or session belongs to. Another tenant's resource answers exactly as one that never existed.
• Our operators, partially, and deliberately not completely. The internal console shows accounts, plans, channels, key metadata and usage so we can support and suspend accounts. It cannot read message bodies or recipient phone numbers, and the audit log that records what an operator did records row ids rather than content.
• Anyone with direct database access — a small number of people, for operations and recovery. Message bodies are stored in plain text in the database; credentials and webhook secrets are not.

Backups

The database is dumped nightly to the same server it runs on, and dumps older than 14 days are deleted. So data you erase can survive in a backup for up to two weeks before ageing out. Backups are not shipped to a third party.

Who else receives it

These are the only third parties that see any of it, and what each one sees:

We do not sell data, we do not share it for advertising, and we do not use your messages to train anything.

How it is protected

• The site and the API are served over HTTPS only.
• Passwords are hashed with Argon2. API keys and sign-in tokens are stored as hashes and compared in constant time.
• WhatsApp session credentials and webhook signing secrets are encrypted before they are written.
• Outbound webhooks are signed, are never sent to a private network address, and redirects are refused rather than followed.

We describe what we do. We claim no certification and no audit, because none has been performed.

Children

Sendbu is a tool for businesses and developers. It is not directed at children and we do not knowingly hold data about them.

Changes, and how to reach us

If this policy changes in a way that affects what we hold or who receives it, we will email the address on your account. Questions, requests and complaints go to [PRIVACY CONTACT ADDRESS — fill in]. Data protection enquiries are handled by [DATA PROTECTION CONTACT — fill in, or state that no DPO is appointed].

See also the terms of service.