If a call fails, run it again by hand. Most teams stop arguing at the fourth: they never reach the concurrency ceiling in the first place. The documented limits sit in a range that the following won't approach: - A small product - An internal tool - A nightly job If you never touch the limit, the machinery built to respect it is dead weight. Taken together, this is a coherent position, and for a prototype, a one-off backfill or a low-volume feature it is correct. Where it breaks is in what it assumes about the day the traffic stops being polite, which is the question the next paragraphs take up. ## Scribe v3 errors and limits that break production **Four things break Scribe v3 in production**: rejected credentials, exhausted quota, rate or concurrency rejections, and files over the documented size or duration limits. Each needs handling before launch, because none of them announces itself in a demo. ### Authentication and quota errors When a key is invalid or revoked, the call returns an authorization failure, and retrying it only repeats the failure. Treat it as a page-the-owner event, not a retry. When the account has run out of quota, every queued job fails until someone changes the plan or the billing. That looks different from a bad key but behaves the same way. The queue should park those jobs instead of burning attempts on them.  I'm not quoting specific status codes or quota sizes here; read them from your own account's documentation and dashboard, and treat anything not stated there as unconfirmed. ### Scribe v3 rate limit and concurrency errors When the vendor rejects a request for sending too many at once, the rejection is a signal to slow down, not a fault in the audio. Cap your worker count below the concurrency your plan allows, so a backlog drains at a pace the vendor accepts. A backlog released all at once is the usual way a polite system becomes a rejected one. ### File size and duration limits If a recording runs past the documented limits on file size and audio length, you must split it before submitting it. Chunk at silences where possible, so you don't cut a word in half, and keep each chunk's offset so timestamps can be stitched back together. Check the limit before upload, and fail the job with a clear reason instead of waiting for the vendor to refuse it. ### Scribe v3 retries, backoff and failure alerts Retry only errors that can clear on their own: rate rejections, timeouts and server-side failures. Space attempts out with growing, randomized delays, and put a ceiling on total attempts. Three recent Speech to Text incidents in the vendor's own history show why. **Plan for jobs to wait more than an hour, and alert on queue age, not only on error counts.** ## Fix Scribe v3 transcription workflows with Activepieces A trigger accepts the job, an action step makes the call, and per-step settings decide what happens when the call fails.  That's the shape the last section asked for, since an hour-long wait is a failure you want handled by a setting, not by a developer awake at night. Here's what it has shipped, and no more. On 2026-09-30 [Activepieces](https://www.activepieces.com/pieces/elevenlabs) ([source](https://github.com/activepieces/activepieces/pull/15981)) to its ElevenLabs integration, reusing the existing API-key connection. Eighty-seven actions means the integration is broad, so you'll have to search the list for a speech-to-text action instead of assuming one exists. Whether any of them covers Scribe v3 transcription, the change as described doesn't say, and we haven't run Scribe v3 through it. Check the action list before you design around it. If no matching action exists, a generic HTTP step carrying the same API key is the fallback. ### What the retry settings do In the screenshot below, a demonstration integration, Gelato, which fetches ice cream flavors, shows the mechanism. A webhook trigger feeds a single selected action step. In the configuration panel, two options matter here: Continue on Failure and Auto Retry on Failure. Beneath them, a test panel reads "Tested Successfully 19 seconds ago," with the step's output underneath.  So a failed call can be retried, or allowed to pass through, without any code from you, and you can test a step against real output before the flow goes live. What the panel doesn't show is queue age. A retry setting handles the call that fails; it doesn't tell you a job has sat for an hour. Build your own queue instead, with a worker, a retry policy and an age alarm, and you get control over those limits at the cost of owning all of it. Activepieces gives you the retry and continue-on-failure settings on each step, so the first version needs no retry code, but the queue-age alarm is still yours to build. ## Scribe v3 pre-shipping checklist Work through six checks in order, because each one catches a failure that the monitoring you build afterward would otherwise find for you, in production, at the worst hour. The first version still works the moment you finish the first request, and that's exactly the risk. From a working key to a calendar reminder, the list below names the failure each step prevents, so you can see what skipping it costs. 1. Keep the key out of the workflow itself. Store it in the secrets manager your platform provides, not pasted into a step. A key in a shared workflow is readable by everyone who can open the workflow, and rotating it later means hunting down every copy. 2. Read your tier's concurrency limit on the vendor's pricing and limits pages. Write the number down next to your expected peak of simultaneous files. If a batch upload can exceed it, you'll find out from rejected requests, not from a warning. 3. Run the minimal request on your longest real file, not the sample clip. The longest recording you actually have, with its background noise and crosstalk. Timeouts and size ceilings only show up at the far end of your data. 4. Add retry and alerting. Retry rejected and timed-out jobs with a growing delay, cap the attempts, and send a human a message when a job exhausts them. A transcript that silently never arrives has no error screen to screenshot. 5. Cost a month from the per-hour price. Multiply your real monthly audio hours by the listed rate, then add a margin for reruns caused by your own retries. Budgets break on reruns more often than on volume. 6. Re-check the vendor pages on a schedule. The model is new, and limits and prices on new models get revised. Put a recurring reminder in a calendar, and compare the pages against the numbers you wrote down in steps two and five. If your volume sits well under the concurrency limit, steps two and four stay short. If it doesn't, a queue in front of the API stops being optional. ## Frequently asked questions Some questions are left over that the vendor's pages answer only in part. Each answer below says where the answer lives and what to do when it is not published. ### Is the Scribe v3 API free to try? Check the vendor's pricing page for the current free-tier terms, because they aren't stated in the body of this article and trial allowances change. The risk is a trial quota that runs out mid-test, so your first retry logic gets exercised by a billing limit rather than a transient error. Make the queue treat that rejection as a stop condition, not something to retry. ### Does Scribe v3 replace earlier models? Does Scribe v3 replace earlier Scribe models? The vendor's model documentation is the authority on which model is current and which are retained. Until you have read it, assume nothing about deprecation dates, because none are confirmed here. Pin the model identifier in every job you enqueue, so a change of model is a deliberate edit you review and not a silent shift in output. ### Which languages does Scribe v3 support? Which languages does Scribe v3 support? The vendor publishes a supported-language list, and that list is the only source worth trusting. Match each language your users speak against it before launch. Being listed tells you a language is accepted, not how accurate the result is, so run a sample of your own audio per language and keep the transcripts you compare. ### Can Scribe v3 transcribe in real time? Can Scribe v3 transcribe in real time? Treat it as a batch service unless the vendor's documentation says otherwise for your endpoint. The design in this article assumes a submitted file and a result that arrives later. If you need live captions, confirm in the docs whether a streaming option exists, and don't build on a reseller's claim alone. ### Where do I check current Scribe v3 prices? Where do I check current Scribe v3 prices? Use the vendor's own pricing page. Resellers and third-party guides quote add-on prices and file limits that can lag behind it, and some figures appear only in those secondary sources. Where the vendor hasn't published a number, record it as unpublished in your plan and ask support in writing, so the answer has a timestamp. ## Related reading - [ElevenLabs Realtime: Scribe v2 Pricing and Features](https://www.activepieces.com/blog/elevenlabs-realtime-scribe-v2-pricing-and-features) - [Scribe v3 Launches: What ElevenLabs' Speech-to-Text Model Changes](https://www.activepieces.com/blog/scribe-v3-launches-what-elevenlabs-speech-to-text-model) - [ElevenLabs Pricing 2026: Plans, Credits, and Costs](https://www.activepieces.com/blog/elevenlabs-pricing-2026-plans-credits-and-costs) ## References - [Toolradar](https://toolradar.com/guides/speech-to-text-api-pricing-compared)Building a scheduler in front of a service whose whole job is to be the scheduler looks like paying twice for the same work.