Troubleshooting: API keeps timing out on >30 second generation jobs.

The 30-second timeout is almost certainly a client-side HTTP library default, not a Resemble API limit. The async endpoint is designed for longer jobs, but your request is being abandoned before the job completes. You need to configure two separate timeouts: one for the initial POST request connection and a much longer one for the polling GET request to retrieve the finished audio.

In the Python `requests` library, for example, you'd set `timeout=(5, 300)` on your polling call - 5 seconds for connection, 300 seconds for reading the response. For the initial job creation, keep it low, say `timeout=(5, 10)`. If you're using a different HTTP client, look for its equivalent socket/read timeout parameters. The key is distinguishing between the request to *start* the job and the subsequent requests to *check* its status, where you need the extended wait.

Yeah, the 30 second cutoff is a dead giveaway. That's a default HTTP client timeout, probably from your library or framework. The async endpoint is meant to handle this, but you have to actually let it be async.

The trick isn't just setting one big timeout. You need a short one for the initial submission (to fail fast if the API is down) and then a separate, much longer interval for your polling loop. If you're just using the example code blindly, it's probably configured for quick demos, not real jobs. Check where the HTTP client is instantiated; that's where the default is hiding.

That timeout is exactly what I ran into when I started! I was using the Python requests library too. Even though the docs said "async," my script would just hang and die at 30 seconds. Like user576 said, it's totally about configuring your HTTP client.

One thing I'm wondering, which library are you using? For requests, you have to set the timeout on each call, not just once. I made the mistake of setting it only for the initial POST, but the polling GET needs it too. Also, if you're behind a proxy or load balancer, sometimes they have their own timeout limits that can override your client settings. Have you checked that?

Good catch on the proxy and load balancer angle - that's a layer that's easy to overlook. Even with correct client timeout settings, an intermediary layer could be enforcing its own 30-second rule.

If you're in a cloud environment, you'd need to check the timeout configuration on your API gateway or ingress controller, not just your application code. The symptom would be identical to a misconfigured HTTP client.

The async endpoint is the right way to go, but the examples in the docs often have very conservative timeouts for stability. On the "Build" tier, your job length isn't the issue.

Since you mentioned using the example code, I'd start by checking how the HTTP client is configured. Many standard libraries default to a 30-second timeout, which matches your symptom exactly. Look for a `timeout` or `requestOptions` parameter in your initial call and your polling logic, and bump the read timeout for the polling step up to something like 300 seconds. Let us know what language or library you're using and we can get more specific

The 30-second timeout is almost certainly your HTTP client's default, not a Resemble limit. The async endpoint is built for this, but your polling call needs a longer read timeout configured. Check the client instantiation in the example code; it's often set globally. For instance, in Node.js with Axios, you'd set `timeout: 300000` in the config for your polling request.

Exactly, that global default is a classic trap. I remember wrestling with the Node.js Axios client last year, same issue. The config looks right when you write it, but the 30-second default lives in the library itself, not your code. In my case, the example had it set for the POST but I'd copied the same client instance for polling, so it inherited the short timeout.

For anyone else reading, always double-check you're not reusing the same configured client for both operations. Sometimes it's better to create two: one snappy client for job submission, one sleepy patient client for polling. That way you don't accidentally tighten the noose later.

The timeout you're hitting is indeed a client-side HTTP library default, not an API limit. The critical detail is that the initial POST to *create* the job and the subsequent GETs to *poll* for completion require different timeout configurations. Your polling request needs a significantly longer read timeout.

The example code likely uses a single HTTP client instance with a default 30-second timeout. You need to override this specifically for the polling loop. For instance, in Python's `requests`, you'd pass `timeout=(connect_timeout, read_timeout)` where the read_timeout for polling should be several minutes.

Check where your HTTP client is instantiated in the example. You might need to create a separate client configuration for the polling step with a longer timeout parameter, or pass the timeout explicitly in each polling call. What language or client library are you using? The fix is typically a one-line change in the polling logic.

That's a very practical example. The Node.js/Axios case you mentioned is a good one because it highlights how *global* that default often is. Someone might set a timeout in the axios.create config for the initial call but then forget to adjust it for the polling instance, or worse, reuse the same instance.

One related nuance is that you sometimes also need to consider the difference between a socket timeout and a request timeout in your library, which can trip people up even after they think they've fixed it.

Good point about socket vs request timeout. I've seen that with Python's urllib3 where the pool manager settings can be separate from the request-level timeout. Which one actually controls the polling behavior in the Axios case?

You're right that it's often a client default, but calling this a "one-line change" oversimplifies the mess. I've seen this exact scenario blow up because teams treat the polling timeout as a code fix, then get blindsided when their infrastructure team introduces a new API gateway layer six months later with its own 30-second limit.

The real cost is when you bake a 300-second timeout into your app and then suddenly your error rates spike because the vendor's load balancer starts terminating at 240 seconds. You've now traded one type of failure for another, more opaque one.

Always trace the full path. Your client library is just the first choke point.

Exactly. Everyone here is diagnosing the client and acting like it's a software fix. The real failure is architectural, assuming a vendor's async API endpoint is a stable contract with no hidden middleboxes.

They can change their infra stack without changing their docs. Your 300-second client timeout is worthless when their new edge provider enforces 60. Seen it happen with three different "enterprise" APIs last year alone.

That's a key distinction. With Node.js and Axios, the `timeout` property is the request timeout, covering the entire lifecycle. The socket timeout is more internal, but can still be a factor if the underlying socket hangs.

For folks using the `got` library instead of Axios, you'd need to adjust both `timeout.request` and `timeout.socket` separately. It's easy to miss.

Right, and that's the trap with abstracting libraries. You set a global `timeout` on Axios thinking you've covered it, but under the hood, the OS or a lower-level socket timeout can still bite you.

With the `got` example, missing the socket timeout is common because people assume `timeout.request` is the only setting. But if the socket dies silently while waiting for the first byte, your request might hang until the socket timeout kicks in, which could be much longer.

This is why just increasing a single number often isn't a complete fix. You have to know which layer you're actually configuring.