Integrating audio with a headless CMS (Strapi, Sanity, Contentful)
When content lives in a headless CMS and rendering happens in a separate frontend, where and when should you voice articles? The realistic integration patterns, without rewriting your stack.
Headless architectures have become common among publishers: content lives in a CMS such as Strapi, Sanity or Contentful, and rendering happens in a separate frontend, often Next.js, Nuxt or Astro. This separation brings flexibility, but it raises a precise question as soon as you want to add an audio version of articles: at which layer should voicing plug in, and when should it fire? There is no single right answer, but a few clear patterns, each with its trade-offs.
The problem specific to headless
In a classic monolithic site, content and rendering sit in the same place, and audio grafts onto the display step. In headless, the source of truth (the CMS) and the presentation layer (the frontend) are distinct. Audio therefore has to find its place without breaking that separation, and above all without forcing the newsroom to leave its usual tool to produce a sound file by hand. The right design is one where the journalist does nothing more than they do today.
Pattern 1: voice at publication via webhook
This is the cleanest approach. Most headless CMSs emit a webhook on each publish or update of an article. You wire that webhook to a process that fetches the text, generates the audio version, and stores the result (or its URL) where your frontend knows to read it. The audio is thus ready by the time the article goes live, with no human intervention.
The benefit is twofold: production follows the editorial rhythm exactly, and nothing changes for the newsroom. The point to watch is handling updates: if an article is corrected after publication, the webhook must re-trigger voicing to avoid a mismatch between the spoken text and the displayed text. It is the same logic described for publication flows in integrate audio with your WordPress, API or RSS articles, transposed to the headless world.
Pattern 2: on-demand API call, frontend side
A variant is to request the audio when a reader opens the article, via an API call, then cache the result. You then voice only the content actually consulted, which avoids processing articles no one will read. This is attractive for a very large long-tail catalogue, where producing audio for everything would be waste.
The trade-off is the first listen, slightly delayed while generation happens, before the cache takes over for later visitors. For a high-traffic site on few articles, pattern 1 remains more comfortable. For a huge catalogue with scattered readership, pattern 2 is more economical.
Pattern 3: an audio field driven from the CMS
A third, more integrated route: expose in the CMS content model a dedicated audio field that the newsroom can view and, if needed, regenerate with one click. Audio then becomes an attribute of the article just like its cover image, versioned and governed inside the editorial tool. This appeals to newsrooms that want to keep control, for example to double-check the pronunciation of a sensitive proper noun before going live.
It requires a little more upfront modelling, but offers the best control. Fine-grained driving, including by automated agents, connects to what we described in driving article audio with AI agents and MCP.
What to decide before writing code
Three questions settle the choice. What is the volume and its traffic distribution? A small number of much-read articles leans towards pattern 1, a long tail towards pattern 2. Does the newsroom want to validate audio before publication? If so, pattern 3 is the one. Finally, where do you store and serve the files so the frontend loads them without weighing the page down? With those answers set, integration comes down to a wiring job, not a rebuild.
In every case, voicing itself stays outsourced: your stack handles neither voices, nor synthesis, nor model updates. The integration's only role is to trigger at the right moment and display in the right place. How this works on the API and CMS side is detailed on our CMS and API page.
Test the integration on your stack
The WeDispatch free tier lets you try voicing today, with your real content: start here. The plans, from 69 to 419 EUR excluding VAT per month, are detailed on the pricing page.
Give your articles a voice with WeDispatch
This blog is itself voiced by WeDispatch. Curious how it sounds on your content?
Book a demo