Add the audio of your articles to a beehiiv newsletter
beehiiv will not play an audio player inside an email, and no mail client does. What works is a button to a page that plays the audio, with the play counted under its origin, the newsletter.
beehiiv has pulled in a lot of newsrooms and independent writers who used to run on other email platforms. Once their articles have audio, the question comes up fast: can we drop the player straight into the edition that goes out to subscribers? The answer has two parts. A technical no, which has nothing to do with beehiiv in particular, and then a simple method that fits in a single block of the editor. Understanding the no saves you an evening of fighting it.
Why no player will play inside an email
An email is not a web page, and that holds for beehiiv as much as for any sending tool. Mail clients (Gmail, Outlook, Apple Mail, the webmails) strip out almost anything that could run inside a received message: no embedded player, no script, and most of the time not even the HTML audio tag. It is an old security rule, not a gap in beehiiv, and it is not going to change. A custom code block holding a player gives the recipient an empty area at best, and a message cut short by the filter at worst.
What does cross every mail client is a link. So the right move is not to make the audio play inside the edition, but to place a link to a page that does play it. beehiiv has one advantage here: every edition has its own hosted web version, where a player could technically appear. But your subscribers open in their inbox first, not on the web version. A setup that only works on the web version leaves most of your audience out. A link works in both places, in the inbox and on the web version, with no conditional setup.
The block that works: a button to the listen page
Every audio WeDispatch produces has a page that plays only that one recording. Not the hub that strings together every audio on the account, not an iframe to wrangle: a standalone page, with the article title, the player, a link through to the full article, and your site's branding (or WeDispatch's, depending on the plan). That is exactly what beehiiv relays without any effort.
In the beehiiv editor, add a Button block (or a Text block with a link on a few words), label it clearly, "Listen to the article" rather than "Click here", and paste the listen page address into the link field. Nothing else to configure: no code block, no extra domain to authenticate beyond what beehiiv already asks for your sends. To produce these audios from a site that also feeds your newsletter, the three possible routes (plugin, feed, programming interface) are laid out on our audio on WordPress page; they hold whatever tool publishes your articles.
One layout note specific to email: put the button high in the edition, near the title of the featured article, where the rushed subscriber decides whether to read, to listen, or to save for later. A listen link buried under five paragraphs will not be seen, and you will wrongly conclude that nobody wants the audio.
Linking the right audio to the right edition
The listen page plays an audio that already exists: no synthesis is run again when a subscriber opens it, so the operation costs nothing no matter how many opens you get. For each article mentioned in the edition, you take its listen page address and paste it into the matching button.
That page follows the same access rules as the rest of your site. An audio that is not ready yet will not be served, and says so, rather than playing a half-finished file. The page always serves the current version of the audio, never an old one left in a cache. And if the article sits behind a paywall for paying subscribers, the page plays the sample and states it plainly, as it would for an anonymous visitor, without quietly opening content you mean to reserve. The principle is the same across email tools, covered in detail in our piece on audio in a newsletter.
The play is counted, under its origin, the newsletter
A play that comes from an edition is only useful if you can tell it apart from the rest. You can. When an audio is played from this listen page, the play is filed under the origin "newsletter" in your account's Plays screen, alongside the other origins: the player on article pages, the public audio page, the podcast feed. The origin is written by the server when it builds the page, not guessed afterward.
Two points touch your subscribers' trust, and they can be checked. The count is anonymous by design: no IP address kept, no audience cookie, no listener identifier. We know a play came from the newsletter, never who made it or from which inbox. Also, the podcast feed is not among the origins counted this way: its episodes go out as a direct file to the listening app, which never passes through our counters. Showing it at zero would be false, so it is not mixed in with the rest. What you read in your listening analytics is therefore what your beehiiv edition actually brought in as audio, kept apart from your site traffic.
What it changes for a newsletter
Audio does not replace reading, it catches the subscriber who would not have opened the article today: the one listening on a walk, in the car, while making dinner. For a newsletter, the point is not the volume of plays on the first edition, it is whether that audience exists among your subscribers at all. The "newsletter" origin, kept separate from the others, tells you without guesswork. You will know quickly, on your own numbers, whether to move the button up a notch or leave it where it is.
Give your articles a voice with WeDispatch
This blog is itself voiced by WeDispatch. Curious how it sounds on your content?
Book a demo