How we look after what you let us read.

Last updated 25 September 2026

braxby asks for access to your calendar, and optionally your inbox. That only makes sense if the access is handled carefully. This page explains, in plain terms, how we do that, and how to tell us if you find a problem. The short version: everything travels encrypted, the keys to your accounts are encrypted again on top of that, only our server can reach your data, and we ask for as little access as the product needs.

1Encryption

On the way

Every connection to braxby, from the website, the web app and the mobile apps, runs over HTTPS (TLS). So does every connection our server makes that carries anything about you, to the database, the AI model, your calendar and mail providers and the rest. Nothing about you crosses the internet in readable form.

At rest

Our database is hosted by Supabase, which encrypts the disks it stores data on with AES-256. That protects everything we hold if a disk is ever lost or taken.

The most sensitive things we hold are the keys that let braxby read your accounts. Those get a second layer. Before they are saved, our server encrypts them itself with AES-256-GCM, using a key that lives only in the server's configuration and never in the database. So even someone who could read the database directly would see scrambled text, not a working key. That applies to:

• Google calendar (and, if you ever grant it, Gmail) access and refresh tokens;
• Microsoft Outlook calendar and mail access and refresh tokens;
• Spotify access and refresh tokens, if you connect Spotify;
• your Sign in with Apple token, and the app-specific password you give us if you connect iCloud Calendar or Mail.

If you create an account with an email address and password, the password is stored only as a salted hash by our authentication provider. Nobody at braxby can read it.

2Who can reach your data

braxby has two halves: the app you use, and a server that does the work. Only the server holds the database key that can read user data, and that key never leaves it.

• The app, on the web or on your phone, never reads your data straight from the database. It asks our server, which checks who you are on every request for your data and only ever returns what belongs to you.
• The only database key the app carries is a public, low-privilege one. As a second line of defence, the database itself refuses that key access to other people's rows: row-level security is switched on for every table that holds something about a user.
• Text that arrives from your mail or calendar is treated as untrusted and neutralised before it reaches our AI model, so a cleverly written email cannot give braxby instructions.

3Connecting your accounts

When you connect Google, Microsoft or Spotify, you sign in on their page, not ours. braxby never sees your password for those accounts; it receives a token that allows only what you approved.

• We ask for as little as we can. Signing in with Google asks for your identity and your calendar only. braxby does not ask for Gmail when you sign in. The exact permissions are listed in the Privacy Policy.
• The handoff cannot be forged. When a connection returns to braxby, it carries a signed code that expires after ten minutes, so a link cannot be tampered with or replayed later to attach someone else's account to yours.
• Refreshing happens on our server. Tokens are renewed server-side and are never sent to your browser or phone.
• Disconnecting deletes the token. Turning off a connection in You → Connections removes the stored token, not just a setting.
• Deleting your account revokes Apple's grant. If you signed in with Apple, we tell Apple to revoke braxby's access before your account is deleted, so nothing lingers in your Apple Account.

4How long we keep things

We keep your data only while your account exists, and deleting your account removes it at once. The full table, including what happens to backups and logs, is in the Privacy Policy.

5Who else is involved

braxby runs on a small number of established providers for hosting, the database, AI, email and payments. Each one, and exactly what it receives, is listed in the Privacy Policy.

6Google data

braxby's use of information received from Google APIs follows the Google API Services User Data Policy, including its Limited Use requirements. What that means in practice is set out in the Privacy Policy.

7Reporting a security problem

If you think you have found a security weakness in braxby, we want to hear about it. Email concierge@braxby.com with what you found and how to reproduce it. We will reply within 3 business days, keep you updated while we fix it, and credit you if you would like.

In scope

• braxby.com and app.braxby.com;
• the braxby server the app talks to;
• the braxby apps on Google Play and the Apple App Store.

Out of scope: the providers we build on (report those to them directly), denial-of-service testing, spam, social engineering of us or our users, and physical attacks.

Safe harbour

If you act in good faith, we will not pursue legal action against you or ask anyone else to. Good faith means:

• you only use accounts you own, or that the owner has agreed you may test;
• you stop as soon as you reach anyone else's data, access no more than you need to show the problem, and do not keep, share or change it;
• you do not degrade the service for other people;
• you give us a reasonable chance to fix the problem before telling anyone else.

Our machine-readable contact details are at /.well-known/security.txt.