Text to speech for websites: one audio file per article

To add text to speech to a website, generate an audio file of each article on your server when you publish or update it, store the file, and play it on the page with an HTML <audio> player. Every visitor then hears the same recording, and synthesis runs once per version of the text instead of on every visit. With Sume, each article is one TTS 1.0 job, POST /v1/tts-1.0/generate, called from your backend.

Sume facts come from the TTS 1.0 schema in the Sume API reference, the OpenAPI document behind the API reference docs, and the Authentication and Media inputs docs. Player behavior comes from MDN's `<audio>` element page. All were read on 2026-09-27. Text to speech API covers every request field.

How do I generate the audio when an article is published?

Run it wherever you already react to publishing, such as a CMS webhook, a build step, or a background job. For each article:

• Send the article's plain text, without HTML markup, as transcript, with one voice for the whole site.
• Derive the Idempotency-Key from the article id and its revision, such as article-812-rev-5. A retry under the same key and body returns the original job instead of billing a second one.
• Pass a public HTTPS webhook_url for a callback when the job ends, or poll its status_url. Callbacks are terminal only (job.completed, job.failed, or job.canceled) and signed, so verify the signature before you trust one.
• Read GET /v1/jobs/{id}/result. In the current code its audio_url is the file on Sume's media host, where Sume mirrors generated outputs. Save that URL with the article or copy the file into your own storage; see how long Sume output URLs last.

Why not call the text to speech API from the page itself?

Because the key would ship to every visitor. A Sume API key spends your credits, and there is no browser-safe variant, so it never belongs in client JavaScript. Browser and mobile clients should call your backend, and your backend attaches the key; calling the Sume API from a browser shows that proxy pattern. Generating on publish also means a page view never starts a paid job.

How do I add the audio player to the article?

An <audio> element with the file's URL is enough. MDN documents that controls gives the listener volume, seeking, and pause and resume controls, and that preload="metadata" fetches only the audio's metadata, such as its length. Browsers differ on the default preload value, which the spec advises be metadata, and they are not required to follow the attribute: it is a hint.

To highlight each word while it plays, also request word timings; see text to speech with highlighted words.

<figure>
  <figcaption>Listen to this article</figcaption>
  <audio controls preload="metadata"
         src="https://example.com/audio/article-812-rev-5.mp3"></audio>
</figure>

What about long articles and edits?

• One request takes up to 20,000 characters, and synthesized audio past 1,200 seconds fails with tts_duration_exceeded, with no credits captured. Split a longer article at paragraph breaks, keep the same voice, and join the parts as in text to speech for long text.
• When the text changes, generate the new revision under its new key and replace the old file, so the audio always matches the page.

How much does article audio cost?

TTS 1.0 costs $0.0475 per 1,000 characters, plus a 5.5% agent fee by default, counted on every transcript character, spaces and punctuation included. At that rate, a 10,000-character article comes to $0.475 before the fee, once per revision. Page views play the stored file and never call the TTS API.