Getting a station onto a smart speaker looks, on the surface, like a paperwork task. Submit a stream URL, fill out some station metadata, wait for approval. In practice, most stations that already run Icecast or SHOUTcast hit a wall before the form is even relevant: the stream itself isn't in a state Alexa will accept.
The certificate problem comes first
Amazon's Alexa Skills Kit requires the audio stream to be hosted at an HTTPS endpoint on port 443, with a valid, trusted SSL certificate. Self-signed certificates aren't allowed, and this isn't a soft warning, the skill build fails outright if a plain HTTP stream URL is entered.
That requirement collides with how most Icecast and SHOUTcast servers are actually deployed. It's common for a station's stream to run over plain HTTP on its own port (Icecast's default is 8000), with HTTPS handled, if at all, only at the website layer, not the stream layer. Getting the stream itself onto a trusted HTTPS address means putting it behind a reverse proxy, typically nginx, terminating SSL there with a certificate from a real certificate authority, and forwarding the connection back to Icecast internally.
This is the step that quietly kills most first attempts at getting a station onto Alexa. The stream works fine in every browser, because browsers have historically been more forgiving about self-signed certs than Amazon's submission pipeline is. The failure only shows up when the RSK build process actually validates the certificate chain.
Bitrate has a real range, and the middle of it is safer than the top
Amazon's documented requirement is a bit rate between 16 and 384 KB per second. The instinct is to offer the best quality available. For a fixed smart-speaker integration, that instinct works against reliability. A higher-bitrate stream takes longer to buffer and has more data that needs to keep flowing without interruption. A speaker has no user watching it to notice or wait out a stutter, it either plays cleanly or produces dead air. 128kbps was chosen deliberately over higher options for exactly this reason.
The catalog format asks questions most stations haven't answered
Beyond the stream URL, RSK expects structured metadata: station name, alternate names, call sign, frequency, and genre from Amazon's own pre-modeled categories. It also asks whether the submitter owns and operates the station or is an aggregator, a distinction Amazon ties to FCC licensing and treats as a real compliance question.
Location narrows who hears the station, but only at the country level
RSK supports location-based search, and it's possible to restrict where a station can play, but only at the country level, not by city, region, or radius from a transmitter.
The underlying idea
The submission form is the last five minutes of a process that's really about infrastructure: a trusted certificate on the stream itself, a bitrate chosen for worst-case network conditions, and metadata precise enough for a listener's voice request to resolve correctly. Skip any of it, and the form will still accept a valid-looking URL. It just won't be one that behaves reliably on a device with no one there to notice when it doesn't.