How to generate audio for every product in your database, automatically

This page may contain affiliate links from which Blur Studio earns commissions.

Generating audio one product at a time through ElevenLabs' own interface works fine until your catalog grows past the point where "by hand" is realistic. The fix isn't a bigger plan, it's connecting your product data directly to ElevenLabs' API so new or updated products get voiced automatically, without anyone sitting down and running each one through manually.

What does the ElevenLabs API actually offer?

ElevenLabs exposes its text-to-speech (and its other audio tools) through a REST API and WebSocket connections, usable from any programming language, with official SDKs for Python (the elevenlabs package) and Node.js (@elevenlabs/elevenlabs-js) if you want a more direct integration than raw HTTP calls. Authentication is a straightforward API key, passed with each request. Every response includes a character-cost figure in its headers, which is the mechanism for tracking exactly how much each generation actually used, useful when you're running this at volume and want to monitor spend as you go rather than finding out at the end of the month.

On cost: API usage is billed per character, and the rate depends on which model you use, with faster models (the Flash and Turbo family) costing meaningfully less per character than the higher-quality models. Different sources quote slightly different exact figures for this, generally somewhere in the range of $0.05 to $0.10 per 1,000 characters depending on the model, so check the current rate for your specific model directly in your account before budgeting a large batch job around it. Critically, this per-character rate is the same regardless of your subscription tier; a higher plan gives you more bundled monthly credits and workspace features, not a lower per-character price. Budget for the per-character rate when scoping a catalog project, not the subscription price alone. If you are weighing providers on price, see ElevenLabs vs OpenAI text to speech.

A worked number to plan around: say your catalog has 5,000 products with an average 150-character description. That's 750,000 characters total, which at the cheaper end of the model range (roughly $0.05 per 1,000 characters) comes to about $37.50 to voice your entire catalog once. On a faster model, that's a genuinely trivial cost for a one-time batch; the real ongoing cost is smaller still, since after the initial run you're only generating audio for new or changed products, not the whole catalog again. That's worth knowing upfront, since the number that scares people off (voicing thousands of products) is almost always smaller in practice than they expect once you actually run the math on character count rather than product count.

What I'd actually tell you if this is your situation

This is a developer task, and I'd say that plainly rather than let you assume otherwise. If you don't have a developer on staff or on call, the real blocker isn't ElevenLabs' API, which is well documented and genuinely not hard for someone who builds software for a living, it's the absence of someone to build the connector. A no-code automation tool like Zapier can cover some simple, lower-volume cases, triggering one audio generation per new product row, but it starts to strain at real catalog scale (hundreds of SKUs, batch processing, error handling when a generation fails partway through) in a way a proper script or service doesn't.

Rate limits are the other thing worth planning for before you fire off a full-catalog batch job. ElevenLabs' API enforces per-second and per-minute request limits that scale with your account tier, so a script that fires thousands of requests as fast as possible will start hitting 429 rate-limit responses partway through, not fail cleanly at the start. A properly built pipeline queues requests and respects those limits with a small delay between calls, rather than assuming it can blast through an entire catalog in one uninterrupted burst. This is exactly the kind of detail that separates a script that works in testing on 20 products from one that actually survives running against 5,000.

Step by step: what a working pipeline actually looks like

1. Count your actual character volume first: total characters across every product description you want voiced, which tells you roughly what this will cost before you build anything, since the cost scales with characters, not with how many products you have.
2. Test a small batch (10 to 20 products) manually through the API to confirm voice choice, pacing and pronunciation work for your specific product copy.
3. Build or commission a script that pulls product text from your database, sends it to the API, and stores the resulting audio file linked back to that product record.
4. Add error handling for failed generations (rate limits, API errors) so one bad request doesn't silently drop a product from the batch.
5. Set it to run automatically whenever a product is added or its description changes, rather than running it as a one-off batch that goes stale.
6. Monitor character cost via the response headers as you scale, so you catch any runaway usage before it shows up as a surprise bill.

Check ElevenLabs' current plans for which tier gives you the API access and bundled credits that fit your catalog's realistic volume.

Storing and reusing the audio you generate

A detail that's easy to miss until it costs you real money: cache and store the generated audio file against the product record, and only regenerate when the underlying text actually changes. A pipeline that regenerates audio on every page view or every API call instead of generating once and serving a stored file is paying the per-character cost repeatedly for output that never changes, which adds up fast at real traffic volume for no benefit. Store the audio file in whatever storage your product images already live in (the same CDN or bucket), link it to the product record the same way an image is linked, and trigger a fresh generation only when the description text itself is edited. Putting the audio on the page is covered in adding audio versions of product pages and how-to pages.

Keep the voice consistent across your whole catalog, the same voice ID used for every product, unless you have a specific reason to vary it (different voices for different product categories, for instance). A catalog where product audio sounds inconsistent from one listing to the next reads as unpolished in a way that's easy to avoid just by locking the voice choice into your pipeline's configuration once, rather than leaving it as a parameter that drifts between runs or between whoever happens to trigger a batch. Tone drift in longer text is covered in why an AI voice changes tone in long audio.

When should you skip building this?

If you're only adding a handful of new products a month, the manual workflow through ElevenLabs' own interface is genuinely fine, and building an automated pipeline isn't worth the development cost yet. The API-driven approach earns its cost specifically once manual generation becomes a recurring bottleneck, not before. A rough line to judge it by: if you're adding or editing more than a handful of products a week, or you already have hundreds of products with no audio at all, the one-time build cost is almost always smaller than the ongoing hours a team spends generating and uploading audio by hand across a growing catalog. Other tools are compared in best text to speech software for business.

How I'd approach this

This exact kind of connector, pulling from your product database, generating audio automatically, handling errors and keeping everything in sync as your catalog changes, is the kind of build I do for clients regularly. If you have the developer resources in-house already, the path above is enough to get started. If you don't, this is precisely the gap I close: I build the connection to ElevenLabs' API from whatever system actually holds your product data, so the audio generation runs itself instead of staying a manual task indefinitely.

A realistic version of this for an ecommerce catalog: a webhook fires whenever a product's description is created or edited in your CMS or database, the pipeline checks whether the audio already exists and is current, generates fresh audio only when needed, stores the file in your existing media storage, links it back to the product record, and logs the character cost for that run so you have a running total rather than a surprise at the end of the month. None of that is complicated individually, but getting all of it working together reliably, including the error handling and rate-limit queuing described above, is where the actual engineering effort goes. Once it's built, it keeps running without anyone thinking about it again, which is the entire point of moving this off a manual task and onto a pipeline.