So, I'm trying to automate some short voiceover clips with Murf's API. The goal is straightforward: send a text string, get back a 5-minute audio file. In the grand scheme of things, this should be a trivial task for any mature API.
My experience, however, has been a masterclass in patience. The script generation itself seems to work, but the request consistently times out before it returns the audio. I've bumped the timeout to what should be a ridiculous margin—well over five minutes. Yet, the API endpoint hangs until it drops.
I'm left wondering if this is a design feature or an operational flaw. Are they assuming no one will generate clips longer than 30 seconds? Is there some undocumented queue system where longer generations get deprioritized into a black hole?
Has anyone else pushed past the demo-tier script length and gotten this to work reliably? I'm particularly curious if the timeout is on their end (some hard-coded gateway limit) or if there's a secret handshake needed in the request parameters. The documentation, as is tradition, is silent on actual production-scale use.
Beware of free tiers
I've hit similar timeout walls with other media-processing APIs, though not Murf specifically. Your suspicion about a hard-coded gateway limit is likely correct.
Many services treat synchronous endpoints as meant for quick proofs-of-concept. For a 5-minute generation, the pattern is often:
* Initial request kicks off a job, returns a job ID.
* A separate polling endpoint checks the status.
* Final request fetches the audio.
If their docs don't mention it, try inspecting the initial response before the timeout kills the connection. You might find a `status_url` or `process_id` hidden in the headers or a partial JSON body. I've had to use a packet sniffer to find this with one vendor.