Buzzsprout’s API Can Now Publish Episodes—but It Still Has No Webhooks

Buzzsprout expanded its API on October 9, 2026, adding episode uploads, transcript editing and directory management for podcast integrations. Developers can now carry a recording through Buzzsprout’s publishing flow, then maintain its transcript and submit an eligible show to directories.

The release leaves status tracking with the integration. Buzzsprout’s API guidance says requests use a podcaster’s token and the service has no webhooks: clients must poll to discover changes. They must also check that uploaded media has finished processing before treating an episode as ready for release.

Episode publishing needs a completed upload

An automated release begins with the podcast’s numeric ID and a new episode. The Buzzsprout API documentation describes creating an episode with a title and keeping it private while its media and details are prepared. Omitting a publication date makes the new episode private by default; setting a future date when making it public schedules the release.

Media follows a distinct upload sequence. The integration starts an upload with a filename, media type and byte size, sends the exact file bytes to the returned upload URL, and calls the completion endpoint. That final call attaches the media to the episode and starts encoding. The file transfer alone does not give the episode attached, playable media.

The upload URL has a different authentication rule from the API requests around it: the client must leave the Buzzsprout authorization header off the file transfer. It then retrieves the episode until processing finishes, using the episode’s duration as the documented readiness signal. Chapters, contributors or artwork can be added before the private episode is changed to public. For an integration publishing from an external production system, the practical boundary is clear: sending audio and publishing an episode are separate operations, with a processing check between them.

Transcript work has two API paths

Transcript maintenance depends on whether the show is correcting a Buzzsprout-generated transcript or supplying its own public file. The generated high-fidelity transcript is made up of timed segments that an integration can fetch and replace. Each replacement segment needs a start time and nonempty text; an end time and speaker label are optional. The API can edit an existing generated transcript, but it cannot create or delete that resource.

A custom public transcript uses a separate upload endpoint and an SRT or JSON file. Uploading it replaces what is shown publicly without turning that file into a Buzzsprout-generated high-fidelity transcript. The public transcript endpoint returns the custom file when one exists; otherwise, it returns an available published generated transcript. Software correcting timed words therefore targets the segment resource, while software delivering an approved transcript file targets the custom upload.

That distinction matters when a show revises names, speaker labels or timing after publication. A replacement segment array must retain the required structure, and an invalid array is rejected without changing the existing generated transcript. Buzzsprout’s on-site editor also received attention that week; an October 14 account of its transcript updates notes the API expansion alongside those editor changes.

Directory submission is a request, then a status check

The listings resource lets an integration retrieve directory records and distinguish shows that are listed, submitted, unlisted or failed. An unlisted destination can appear even if it has never received a submission. This gives a service operator a way to inspect the show’s distribution state before making another request.

An account admin or owner can submit the show to remaining eligible one-click directories in a single API request. Destinations that require a manual process are left alone. The response can show a directory as submitted, which means the request is pending rather than that the show is already listed; the client must retrieve the listings later to see whether the state becomes listed or failed.

Submission also depends on the podcast being ready. The account email must be verified, and the show needs a published episode, artwork, a description, an author and a category. For a new podcast, creating a private episode is therefore insufficient to submit it through this endpoint. An eligibility error and a pending directory submission call for different handling in an automated workflow.

Tokens and polling remain developer work

API calls use HTTPS, a token in the authorization header and an identifiable User-Agent. A podcaster obtains the token under Profile → API, while podcast-scoped requests use the show’s numeric ID. An integration serving several shows needs to keep each show’s credentials and ID with the operations performed on its behalf.

Polling has two immediate jobs in the expanded workflow: checking an episode after upload completion and revisiting directory records after submission. For responses with ETag or Last-Modified headers, conditional requests let a client check for changes without downloading an unchanged resource again. The documentation also specifies a per-token rate limit and advises backing off after throttling or transient server errors.

The result is a broader publishing API with a continuing timing responsibility for developers. A release can be prepared and scheduled through API calls, but its media-processing state and later directory outcomes become known to an external system only when that system asks for them.

Also read:

• Spotify Is Selling Its Internal Developer Stack—Four Tools Now Share One Home
• Patreon API v1 Is Off—Old Membership Webhooks Need a Rewrite
• Phone Numbers as Machine Identifiers: Where SMS Still Sits in Modern Systems