Podcast and Audio Hosting with the AIOZ Stream API

AIOZ Stream's own API documentation uses "My Podcast Episode" as its example title for creating an audio object. That's a real signal of intended use, and it's worth being precise about what the Audio API actually provides before assuming it means what "podcast hosting" means everywhere else: storing, transcoding, and streaming audio is one part of podcast hosting. Getting a show into Apple Podcasts and Spotify is a different mechanism entirely, and it's not one this API includes.

TL;DR:

• The Audio API reuses the same create/upload-part/complete media pipeline as video, just with "type": "audio" instead of "type": "video", and AAC as the only supported codec.
• Quality is set with preset labels, "standard", "good", "highest", "lossless", rather than resolution strings, alongside 9 selectable sample rates from 8kHz up to 96kHz.
• There's no RSS feed generation anywhere in AIOZ's documentation. RSS is the actual mechanism podcast apps use to discover and display a show, per how established podcast hosts like Buzzsprout describe their own core function, and AIOZ Stream doesn't provide it.
• That makes this a real audio streaming and storage API, not a podcast host in the industry-standard sense, unless a developer builds an RSS layer on top of it themselves.
• No audio-specific transcoding rate is published; the payment docs only list video pricing, so calling /media/cost with type: audio is the way to get a real number.

What the Audio API actually is

Audio doesn't get a separate set of endpoints, it runs through the same media pipeline this series already covered for video: create the object with a POST to /api/media/create, upload one or more parts to /api/media/:audio_id/part, then call /api/media/:audio_id/complete once every part is up. AIOZ's own documented example makes the audio-specific shape concrete: a qualities array with "resolution": "highest" at a 320,000 bps AAC bitrate and "resolution": "standard" at 128,000 bps, both at 44,100 Hz, stereo, tagged with a BCP-47 language code. Retrieve, update, list, and delete endpoints work the same way they do for video, keyed to an audio_id instead of a video_id. The infrastructure is genuinely shared, which is worth knowing if you're already integrated with the video side, the same chunking, hashing, and completion pattern from the chunked upload tutorial applies here without modification.

AAC only, and quality presets instead of resolutions

Codec choice isn't a decision on the audio side the way it is for video: AAC is the only supported option, no equivalent of the H.264/H.265 choice covered in the 4K/8K encoding article. What is configurable is quality tier, expressed as one of four preset labels, standard, good, highest, or lossless, rather than a resolution string, plus a sample rate chosen from nine documented values spanning 8,000 Hz (roughly telephone quality) up to 96,000 Hz (studio-grade), and a bitrate field that AIOZ's own docs recommend keeping between 128,000 and 256,000 bps for most content. A multi-quality ladder works the same way it does for video, multiple objects in one qualities array, letting a listener's connection pick between, say, a lossless tier and a smaller standard tier without a separate API call per quality level. The practical reason to bother with more than one tier at all is the same logic covered in the bitrate ladder article for video: a listener on a weak mobile connection benefits from a smaller standard-tier stream the same way a viewer does from a lower-resolution video rendition, even though audio files are small enough relative to video that the stakes are lower and a single well-chosen tier is often good enough for a lot of use cases.

What "podcast hosting" actually requires, and what's missing

This is the honest gap worth naming directly. Buzzsprout, an established podcast host, describes the job plainly: "Podcast hosting is the service that stores your podcast files, creates your RSS feed, and helps podcast apps display your show to listeners." The RSS feed isn't a nice-to-have alongside file storage, it's the actual mechanism Apple Podcasts, Spotify, and every other podcast app use to discover a show and its episodes at all; without one, a show doesn't exist to those apps no matter how well the audio files themselves are hosted. AIOZ's API documentation, checked directly across the Audio API reference and the general FAQ, has no RSS feed generation, no episode-and-show organizational structure built for that purpose, and no mention of Apple Podcasts, Spotify, or podcast-app distribution anywhere. What AIOZ Stream's Audio API actually provides is the storage, transcoding, and adaptive-streaming layer, real infrastructure, just not the specific distribution mechanism the word "podcast" implies to most people evaluating a host. It's worth seeing exactly how specific that mechanism is, since "just add an RSS feed" undersells the actual requirements. Apple's own podcast requirements specify an RSS 2.0 feed carrying the iTunes podcast namespace, a publicly addressable URL with no password protection, and a unique, permanent GUID per episode alongside a required <enclosure> tag naming that episode's audio URL, file size, and MIME type explicitly. None of that is exotic engineering, but it's a real, separate structured-data layer with its own formatting rules, distinct from hosting the audio bytes themselves, and it's the layer AIOZ Stream's API doesn't provide.

What this API is actually good for

None of that makes the Audio API pointless for audio content, it changes what it's actually suited for. An in-app audio player, a members-only audio archive, background audio for a product that isn't primarily a podcast app, or the storage-and-streaming layer underneath a podcast product a developer is building from scratch, all fit this API's actual feature set well. That last case is the real path to using AIOZ Stream for something recognizable as a podcast: build or use a separate RSS-generation layer, there are open-source and hosted options for exactly this, and point it at AIOZ Stream's hosted, adaptive-bitrate audio URLs rather than expecting the platform to generate and syndicate the feed itself. That split, AIOZ Stream as the media layer, a separate service or a small custom script as the feed layer, mirrors how a lot of infrastructure actually gets composed: an <enclosure> tag just needs a stable, publicly reachable audio URL and its file size, which is exactly what a completed AIOZ Stream audio upload provides once transcoding finishes. Generating the surrounding RSS XML from a list of episode metadata, title, description, publish date, that enclosure URL, is a comparatively small script to maintain once the harder problem, reliably hosting and adaptively streaming the actual audio at scale, is handled by infrastructure built for it.

The pricing gap

AIOZ's payment documentation lists storage, delivery, and video transcoding rates directly, and doesn't list a separate audio transcoding rate anywhere on that page, the only audio reference there is a navigation link out to the Audio API docs, not a price. Storage and delivery are very likely billed the same way regardless of media type, since audio files pass through the same GB-based storage and delivery mechanics video does, but that's an inference, not a documented fact, and audio transcoding specifically has no stated per-minute rate the way video's HD/2K/4K tiers do. The same /api/media/cost endpoint covered in the 4K/8K encoding article accepts type: audio, which makes it the way to get a real number rather than assuming audio pricing mirrors video's published tiers.

Frequently Asked Questions

Can I use AIOZ Stream to publish a podcast to Apple Podcasts and Spotify?
Not directly. AIOZ Stream can store, transcode, and stream the audio files, but it doesn't generate the RSS feed those platforms require to discover and display a show; that layer would need to come from elsewhere.

What audio codec does the API support?
AAC only. There's no codec choice on the audio side the way there is between H.264 and H.265 for video.

What sample rates are available?
Nine documented options, from 8,000 Hz up to 96,000 Hz, selected per quality object in the qualities array.

How is audio quality configured, if not by resolution?
Through preset labels, standard, good, highest, and lossless, each with its own bitrate, sample rate, and channel configuration.

Does audio use the same pricing as video?
Storage and delivery likely do, since both are billed by GB regardless of media type, but that's not explicitly documented. Audio transcoding has no published per-minute rate the way video does; call /media/cost for a real number.

Is the Audio API still useful without RSS support?
Yes, for in-app audio players, member-only archives, or as the storage/streaming backend under a podcast product that adds its own RSS generation layer separately.

Related Reading

• Video Container Formats Explained: how container choice applies on the audio-only side of the same platform
• Media Chapter vs Media Transcript API: The Real Differences: another pair of AIOZ APIs that store what you provide without generating it for you
• How to Encode 4K/8K Video via the API: H.264 vs H.265: the video-side quality/codec configuration this article's audio equivalent is compared against
• Chunked Video Upload Tutorial: 50-200MB Parts Explained: the shared upload mechanics this API reuses for audio
• AIOZ Stream Developer Guide: the full API surface this Audio API is part of

References

• AIOZ Stream Audio API documentation: the endpoints, codec, quality presets, and sample rates cited above
• Buzzsprout: What Is Podcast Hosting: the RSS-feed-as-core-mechanism definition cited above
• Apple Podcasts: RSS Feed Requirements: the enclosure-tag/GUID/namespace requirements cited above