Build a Podcast Reading Pipeline With the Podwise CLI and API
A five-stage pipeline — find, filter, fetch, store, publish — with the commands and endpoints that make a weekly digest run itself.
Guide5 min read
Every team has a version of this problem: a dozen podcasts matter to the work, nobody has time to listen, and the person who used to send a Friday summary changed roles. The work does not need a better reader. It needs a pipeline that runs whether anyone remembers it or not.
This is the build we use: five stages, each one small enough to debug on its own.
Stage 1: find the episodes
Start from something you already have: the shows you follow, a search query, or a list of links someone sends you.
With the CLI:
podwise search episode "developer hiring" --limit 20
podwise popularWith the API, discovery is a set of endpoints under /api/open/v1 — search episodes, list a podcast's episodes, or pull what is popular. If you already know the episode, skip this stage: the seq number in https://app.podwise.ai/dashboard/episodes/1234567 is all you need.
Stage 2: filter hard
The pipeline only works if it throws things away. Two filters earn their keep:
- Show allowlist. Ten shows, not the whole index. A digest nobody asked for is noise.
- Age. Last seven days. Backfilling is a separate job and it will blow your credit budget.
If you are following the shows in Podwise, list_followed_episodes gives you new episodes with dates, which saves a search step.
Stage 3: fetch the content
Fetching is free for anything already processed. Processing something new costs one credit per episode or video, so keep this stage honest and log what it spends.
The CLI writes to stdout, which is the whole point:
podwise get summary https://app.podwise.ai/dashboard/episodes/1234567 > summary.mdWith the API:
curl -s "https://podwise.ai/api/open/v1/episodes/1234567/summary" \
-H "Authorization: Bearer $PODWISE_TOKEN"Under the hood the summary comes back as sections: overview, takeaways, chapters, highlights. The API can also return Q&A, keywords and the mind map on request; the endpoint reference lists the fields.
For anything unprocessed:
podwise process https://app.podwise.ai/dashboard/episodes/1234567Then wait. Processing is asynchronous; poll the status endpoint rather than hammering the summary endpoint.
Stage 4: store it
Keep the raw output. A JSON file per episode, or a row in a table, with four columns: seq, show, published, summary. The reason is boring and decisive: when someone asks "where did this claim come from", you can answer in ten seconds.
If you are storing Markdown, put the source URL at the top. If you are storing JSON, keep the section names exactly as the API returns them — do not rename takeaways to bullets and then wonder why the renderer breaks.
Stage 5: publish
Three shapes cover most teams:
- A Markdown digest committed to a repo and built as a page. One heading per episode, three takeaways each, link to the source.
- A Slack post on Friday. Same content, different formatting, plus a "worth a full listen" line.
- A Notion page in a database with the show and date, so the archive is searchable.
The formatting is a template; the decisions are not. Pick the two episodes worth attention and say why. A digest that lists everything is a feed, and feeds get muted.
Scheduling and the money question
Run it once a week, not every hour. Cron at 06:00 on Friday, one job, with a timeout and a log line per episode.
Two costs to watch:
- Credits. Discovery and reading processed episodes cost nothing; processing new ones costs credits. Put a hard cap in the script: if the episode count is over ten, stop and ask.
- Rate limits. The Enterprise API allows 10,000 requests per hour per user; a 429 response tells you to wait for
Retry-After. A weekly job will never come close unless something is looping.
Authentication is one token: create it in Settings › Developer, send it as a Bearer header, and keep it in the environment, not in the repository. The authentication page covers the CLI's own login as well.
Why not just use the MCP server?
If a person is going to read the output, an assistant with the Podwise plugin can do stages 1–4 in a chat, and the MCP guide is the shorter path.
A pipeline is the right answer when the output has to exist without anyone asking: a page that rebuilds every Friday, a table that accumulates, a job that runs while the team sleeps. Same data, different trigger.
The part everyone skips
Write down what the pipeline does when it fails. An empty digest, a stale one, or a Slack message that says "3 episodes could not be fetched" — pick one and make it visible. Silent failure is the reason internal tools lose trust, and a digest nobody trusts is worse than no digest at all.
