TTS API data retention: we don't keep your scripts — Audra

Audra retains different data for synchronous renders, background jobs, account operations and billing. See /privacy for the service policy; this post summarizes the first-party processing paths.

Background job text and audio

Background speech jobs persist the submitted text while processing and store generated audio for polling and download. Completed or failed jobs become eligible for cleanup after a configurable period, 24 hours by default. Queued jobs and delayed cleanup can remain longer; this is not a guarantee that every copy disappears exactly 24 hours after submission.

Synchronous renders and the audio cache

Synchronous requests process text to produce an MP3/WAV response. Successful audio may be retained in an in-memory render cache until byte-budget eviction or service restart. Requests above 8,000 characters on /v2/speech become background jobs by default unless X-Audra-Sync: true is sent.

Account and operational records

• Account email, hashed API keys, credit ledger, billing events and usage counts are retained separately.
• Idempotency records protect billing. A duplicate or in-progress key returns HTTP 409 rather than replaying audio; retain the original response or job ID.
• Railway hosts the gateway/database and Modal processes speech. Stripe handles payments; configured email providers deliver account emails. Optional Google sign-in and self-hosted Umami analytics have separate data paths.
• Provider infrastructure and operational logs may have their own retention. Do not assume that an in-memory render means zero retained data throughout the delivery chain.

Model training and your own storage

Audra does not use customer content to train or fine-tune models. Your application controls its own audio storage and logs; include both those systems and Audra job/cache retention in your data map. Contact hello@audratalks.com for retention questions.