Privacy policy

Who we are

Brevcast turns podcast episodes into short written and spoken summaries. We decide what data the service collects and why, which makes us the controller of it.

Brevcast is operated by Brevcast B.V., Prins Hendrikkade 82c, 1012 AE Amsterdam, the Netherlands.

For anything on this page, including a request about your own data, write to support@brevcast.com.

What we collect

Only what the product needs to work, plus a privacy-minimised measure of how the product is used. There is no advertising network and no third-party marketing pixel in Brevcast, so there is no profile of you built for advertising. The product analytics we do run records events tagged with internal ids and coarse buckets only, never the names of the shows or episodes you listen to, never any free text and never your email. It does record the internal id of a briefing you ask us to make and the account it belongs to, which we can trace back to the episode through our own database, so it is a record of what you requested rather than an anonymous one.

• Your email address. It is how you sign in: we send a magic link and a one-time code, so there is no password to store. A display name is created alongside it at signup from what your sign-in provides.
• Your settings: interface language, whether you prefer the long or the short listen, which voice reads your briefings in English and in Dutch, and the time of day you want to be notified.
• What you follow and what you ask for: the shows you subscribe to, the briefings you request, and the topics you skip inside one.
• Your listening progress: your position in a briefing and whether you finished it.
• Feedback you send from inside the app, together with the screen you sent it from and whether you asked us to reply by email.
• Links you paste in to be resolved into a show. We keep the link exactly as you pasted it, together with the outcome, so we can see which links work and which fail.
• Your subscription state: plan, status, renewal date, and the identifiers our payment provider uses for you. Card numbers never reach us at all.
• Ordinary technical data: server logs, the IP address a request came from (used to rate-limit abuse), and error reports when something crashes.
• A privacy-minimised record of how you move through the product, so we can see where the experience works and where it does not. Each event is tagged with internal ids and coarse buckets only, and carries no show or episode titles, no free text and no email. The ids include your account and the episode you asked us to summarise, which we can trace back through our own database.

Why we use it, and what allows us to

Data-protection law wants both the reason and the legal ground for each use, so here are both, in plain terms.

• To run the account you asked for: signing you in, making the briefings you request, remembering where you stopped listening, and billing the plan you chose. The ground is that we cannot perform the contract you entered into without it.
• To keep the service standing up and to understand how it is used: rate-limiting abuse, finding crashes, stopping fraud, seeing which pasted links fail so we can fix the resolver, and measuring in a privacy-minimised way which steps of the product people reach so we can improve it. The ground is our legitimate interest in a service that works, is not abused, and gets better, weighed against the fact that none of it profiles you or records what you listen to.
• To act on feedback you send us. The ground is our legitimate interest in fixing what you tell us is broken. The feedback form also carries a tick-box asking whether we may reply by email; it starts ticked, so clear it before sending if you would rather we did not.
• To keep records the law requires us to keep, such as what we are billed for. The ground is our legal obligation.

Who else receives it

These are the companies that end up holding some of it, and what each one gets. Data reaches them in two ways: we send it, or your browser sends it directly, and for several of them it is both. A request your browser makes itself never passes through us, so it shows them things a request from our servers would not, starting with your IP address. Each entry below says which way applies to it.

• Supabase: our database and sign-in system. It holds your account, your settings, your library and your listening progress, and it sends the sign-in emails.
• Vercel: our hosting. Every request to Brevcast passes through it, so it sees the request itself, including your IP address.
• Cloudflare R2: where the audio of your briefings is stored, and also where your browser plays it from. The stored files sit under a briefing identifier and carry no account details. Playing one does not stream through us: we hand your browser a short-lived signed link and it fetches the audio from R2 itself, so R2 sees that request as well, including your IP address, which briefing you asked for, and which byte ranges your browser asks for, which is how skipping and seeking show up.
• Polar: our checkout. Polar sells Brevcast subscriptions as an authorised reseller and merchant of record, so the purchase and the invoice are theirs. Starting a checkout sends them your email address, the IP address of that request (they use it to work out the right tax), your Brevcast account id, which plan and billing cycle you picked, whether you are taking a founding-member place, and the discount that goes with it if you are. Card details go to Polar and never reach us.
• Sentry: crash and performance reports. We do not attach your account identity to them, session recordings mask all text and block media, and signed media links are stripped before anything is sent. Some reports do carry the identifier of the briefing that failed, which we can trace back to an account through our own database.
• PostHog: our product-analytics tool, on its European (Frankfurt) cloud. It receives the funnel events described above, tied to your internal Brevcast account id so we can measure how people sign up, reach their first briefing, and upgrade. The browser sends its events to PostHog directly rather than through us, so PostHog also sees the IP address of those requests. The events carry internal ids and coarse buckets only, never show or episode titles, free text or your email, so they are pseudonymous. Session recording is off and it is set to keep no cookie.
• Transcription, summarisation and voice providers: today AssemblyAI, Mistral, Anthropic, OpenAI, Google, xAI and DeepInfra, plus Brave Search and Podcast Index for looking shows up. They receive the episode material we are working on, not your account details. Which of them runs a given step is a setting we can change.
• Whatever server a show keeps its files on: cover artwork is loaded straight from the address in the feed, so that server is contacted by your browser whenever a cover image is on screen. The same happens with the audio when you play a full original episode instead of a briefing: it streams from the address the feed gives, exactly as it would in any podcast app. Those requests go from your browser to that server without passing through us, and it sees what any web request shows, including your IP address and which file was asked for.

Where it is processed

The providers above operate in different places, and some of them process data outside the European Union. Which region applies to each one, and the transfer safeguards that go with it, are being confirmed and will be stated here rather than assumed. That includes the region our crash reporting runs in, which is a setting rather than something the product decides. The product-analytics provider is the exception we can state now: it runs on its European cloud.

How long we keep it

Your account data, your library and the audio of your briefings live for as long as your account does. There is no automatic expiry today, and if we add one this page will say so.

Deleting your account removes them. Some things deliberately outlive it, and we would rather be plain about what that means than let you assume otherwise. The feedback you sent and the links you pasted are kept, with the account reference removed. The content itself is not altered: your feedback still says whatever you wrote, and a pasted link is stored exactly as you pasted it, which can include identifying or sensitive parts of a URL. There is no cleanup schedule on either of them today, so they are kept indefinitely.

An email address given to an early-access sign-up form we have since retired may still be stored, and an older entry can also carry the plan that person said they were interested in. That form is gone and so is the part of the site that received it, so nothing is added to this any more. Those entries sit apart from your account, so deleting an account does not remove them, and whether we keep or erase what was already collected is still being decided.

Logs and crash reports age out on the schedules our hosting and monitoring providers apply to them.

Product-analytics events sit with PostHog, apart from your account, and are not part of what account deletion erases today. They are pseudonymous, keyed to an internal account id with no name, email or titles, and PostHog keeps them under its own retention. Erasing them when you delete your account is something we still have to add.

Deleting your account

Open Account and choose Delete account. You are asked to confirm, and then it runs.

It cancels any paid subscription at our payment provider first and confirms the cancellation before erasing anything. If that confirmation fails, the deletion stops there and nothing at all has been erased. It then erases the audio of your briefings from storage, and finally removes your account, which takes your profile, your briefings, your topic choices, your listening progress and your subscriptions with it.

We are not going to promise that this can never go wrong. A subscription started in the last moments before you deleted can slip past the cancellation, and we sweep for that afterwards without being able to guarantee it. If you are ever charged after deleting your account, write to us and we will stop it and refund you.

There is no soft delete and no recovery window. Once the erase has begun it cannot be rolled back, so a failure partway through can leave some audio already gone. The message you get says which of those two situations you are in rather than guessing, and if anything is left behind, writing to us is the way to finish it.

Your rights

You can ask for a copy of your data, ask us to correct it, ask us to delete it, ask us to restrict how we use it while a dispute about it is being sorted out, object to a use that rests on our legitimate interest, or ask for your data in a portable form.

Account deletion is available to you directly, at any time, without asking us.

Write to support@brevcast.com and we will handle it. We do not sell your data and we do not share it for anyone else to advertise to you. If you think we have handled your data badly, you can also complain to the data-protection authority where you live.

Cookies and similar storage

Your browser holds a sign-in cookie, which is what keeps you signed in between visits.

It also holds a set of small preferences: your light or dark theme, your playback speed, which library tab you were on, how you had your summaries filtered and sorted, and where you had got to in onboarding. Most of those stay in the browser. One of them, the way you sort and filter your summaries, is also written to a cookie and sent to us on every request, so the page can render in the order you left it instead of reshuffling in front of you.

There are no advertising or analytics cookies. Our product analytics keeps no cookie; instead it stores an identifier, together with a little device and session information, in your browser local storage, so your visit holds together across pages. Once you sign in that identifier is tied to your account, and it is cleared when you sign out. That is first-party storage on this site only, not a cross-site tracker, which is why Brevcast still does not ask you to accept advertising or analytics cookies.

Changes to this policy

When something here stops being accurate we change it and move the date at the top. If a change matters to you, for example a new recipient of your data, we will tell you rather than quietly edit the page.