Privacy Policy

When you sign in, our authentication provider (Clerk — see Section 5) handles your password / OAuth tokens and shares with us a stable user ID, your email address, and your account avatar (if you set one). We store the ID and email in our database to associate you with the podcasts and guest profiles you control.

When you submit an RSS feed, we fetch and cache its contents (show title, description, cover artwork, episode list, and any Podcasting 2.0 namespace tags the publisher has set, including <podcast:person> attributions, transcripts, chapters, alternate enclosures, podroll, and funding links). This data comes from the public RSS feed you point us at.

We also enrich a feed with metadata from the Podcast Index API (see Section 5) — typically genre, owner email, and platform listings.

When a podcast we host credits you as a host, guest, or crew member via <podcast:person> entries in its RSS feed, we record that credit against the show. Each credit is scoped to that specific podcast — there is no cross-show guest profile and no public profile page. Name, photo, role, and any URL come from the publisher's feed.

Credits surface in the “Appearances” section of the show's PodSocial page and in the per-episode person row on each episode page. If you are credited and would like the credit removed, contact us — see Section 7.

When listeners visit a podcast page, listen to an episode, click out to a podcast app, or follow a podcaster’s tracked link into the platform, we log an anonymous event recording the podcast (or episode, or tracked link) and a country code derived at the edge from the request. For page visits we also record the origin of the referring site (e.g. theverge.com) when the browser shares it — never the full URL or query string — so podcasters can see where their inbound traffic comes from. We do not store IP addresses or user-agent strings, and we do not associate listener events with any signed-in user.

Aggregate counts (plays / views / clicks / tracked-link clicks) are surfaced on owner dashboards. Tracked-link clicks may be pivoted by the owner-defined tags attached to each link (e.g. Source, Campaign, Guest) but the click record itself never identifies a listener. The raw events are retained indefinitely in their anonymous form to support historical reporting; we may revisit retention as the dataset grows.

Account and sign-in emails (verification codes, password resets) are sent by our authentication provider, Clerk (Section 5), as part of running your account. If we send you any other transactional email, we keep a record of the message and its delivery status via Resend (Section 5). We do not send marketing email and we do not have a newsletter.

When you use the RSS Health Check tool at /rss-check we do not store the contents of your podcast feed. The feed is fetched, validated in memory, and the report is returned to your browser. We log the URL you checked alongside basic request metadata (hashed IP for rate limiting, timestamp, result code) for up to 30 days for security and abuse-prevention purposes. Results are saved in your browser's local storage so you can compare scores between checks; they are never transmitted to our servers after that initial validation.

For podcasts you have claimed, we run the same RSS Health Check automatically as part of our hourly feed-refresh process and store a short summary on your podcast record (score, band, issue counts, Apple Podcasts and PSP-1 compliance flags, and a checked-at timestamp). The summary is displayed in your dashboard so you can see your feed's current health at a glance. The underlying data is derived entirely from your public RSS feed; we don't collect anything new for this purpose. Removing the podcast (or your account) removes the summary alongside everything else.

For claimed podcasts where the owner has enabled the reviews feature, we cache reviewer-submitted content from Apple Podcasts' public customer-reviews feed (review text, title, rating, reviewer display name as published on Apple Podcasts, and the storefront the review came from). Reviews are fetched on demand when the podcast owner clicks "Sync reviews" in their dashboard; we do not run automated background syncs. The data is publicly available on Apple Podcasts itself; we cache it so it can render on the show's PodSocial page. Removing the podcast (or your account) removes the cached reviews alongside everything else. We don't cache or surface reviews from any storefront for podcasts that have not been claimed.

Owners can pick a country in the reviews customise panel — used by the reviews fetcher as an additional storefront, and (separately, off by default) optionally displayed as a public "location" flag and name next to the author on the show's PodSocial page. Owners can also add an optional free-text city (e.g. "Oxford") shown alongside the country when the toggle is on. Both fields are only published when the owner explicitly enables the "Show country as location" toggle. We don't store any other location data about the owner. Removing the podcast removes them alongside everything else.

When a podcast owner clicks "Suggest tags" on an episode in the customise panel, we send the episode's title, description, and (when available) the first ~6,000 characters of its published transcript to Anthropic's API. Claude returns a short list of suggested topic tags from our canonical vocabulary, which we cache against that episode so re-clicking the button returns the same set without a second API call. Suggestions are never applied automatically — the owner reviews and chooses which (if any) to add to the episode. The data we send is already public (episode metadata is published in the show's RSS feed; transcripts are owner-published). No PodSocial account data or analytics is sent. Anthropic's data-handling terms are at anthropic.com/legal/commercial-terms. Removing the podcast removes the cached suggestions alongside everything else.

Support is handled over email — write to matt@storyninetyfour.com and the thread lives in our regular email provider's inbox like any other email. We don't collect support messages through any in-app form or store them in the PodSocial database.