Roast keeps the product honest by answering the obvious questions about aliases, feeds, personalization, billing, and private data handling directly.
Roast uses private account state, a private RSS feed, and non-public user routes.
Roast is built around private account state and a private RSS feed, not a public catalog. The feed URL is a bearer capability, so keep it private and rotate it if it leaks.
Forward only mail you control or are authorized to process.
No. Roast requires that you control or are authorized to forward the content you submit. The product is not a loophole for processing private third-party mail you do not have rights to use.
Delays can happen in script generation, local TTS, or in the podcast client refresh window.
Check the inbox item first. If Roast says ready, the remaining delay is usually your podcast app refresh cadence. If the item is still script_pending or script_ready, the delay is still inside Roast’s processing path.
Alias failures usually come from using the wrong address or from account state changes.
First confirm that you are using the exact alias shown in /my. Then confirm that the account is still active. Unknown or blocked aliases reject at the edge before Roast can create an inbox item.
Yes. Rotation invalidates the old feed URL immediately.
Yes. Rotate the feed from /my/billing when the URL leaks or a client gets stuck. Every podcast app must then be updated to the new URL.
Stripe remains the billing source of truth, and the billing portal is the operational control surface.
Yes. Use the billing portal from /my/billing to review or cancel the subscription. Roast does not hide billing state inside a custom settings maze.
Roast may combine onboarding inputs with AI generation and public-web research for personalization.
Yes. Roast may use AI generation and public-web research to enrich personalization. User corrections remain authoritative, and the profile surface makes the core state visible instead of burying it.