Chatterbox-TTS Server Returns 404 When Connected to Open WebUI (Docker Setup)

[connectnet]

Hi everyone,

I’m trying to integrate Chatterbox-TTS (by @devnen) with Open WebUI in a Docker environment, but I’m running into a 404 Not Found error when Open WebUI attempts to connect to the TTS server. Here’s what I’ve tried so far:

---

Setup

• Chatterbox-TTS Server:
  • Running in Docker on port 8004 (exposed to 0.0.0.0).
  • Confirmed working via curl (see below).
• Open WebUI:
  • Also running in Docker, configured to use Chatterbox as the TTS provider.
  • Both containers are on the same Docker network (bridge by default).

---

Steps Taken

1. Verified Chatterbox is running:

   curl -X POST http://localhost:8004/v1/audio/speech \
     -H "Content-Type: application/json" \
     -d '{"model": "tts-1", "input": "Test", "voice": "alloy"}'

   • Response: Returns audio data (works as expected).

2. Configured Open WebUI:

   • TTS provider set to "Custom API".
   • URL: http://chatterbox:8004/v1/audio/speech (using Docker service name).
   • HTTP method: POST.
   • JSON body:

     {
       "model": "tts-1",
       "input": "{{text}}",
       "voice": "alloy"
     }

3. Tested connection from Open WebUI:

   • Open WebUI logs show a 404 error when attempting to send TTS requests.

---

Error Details

• Open WebUI Logs:

  ERROR: TTS request failed with status 404
  

• Chatterbox Logs (no errors, but no incoming requests either):

  INFO:     172.17.0.1:8004- "POST /v1/audio/speech HTTP/1.1" 404 Not Found
  

Possible Causes

1. Incorrect API Endpoint:

   • Is /v1/audio/speech the correct path for Chatterbox? The docs are unclear.
   • Tried /synthesize and /tts as alternatives, but same 404.

2. Docker Networking Issue:

   • Both containers are on the same network, but Open WebUI might not resolve chatterbox:8004 correctly.
   • Tested with curl from inside the Open WebUI container:

     docker exec -it openwebui curl -v http://chatterbox:8004/v1/audio/speech

     • Returns 404, but curl http://localhost:8004/v1/audio/speech (from host) works.

3. Missing Headers/Authentication:

   • Chatterbox doesn’t require an API key, but Open WebUI might send extra headers causing issues.

---

Questions

1. What is the correct API endpoint for Chatterbox-TTS?

   • The OpenAI-compatible /v1/audio/speech works with curl, but not from Open WebUI.
   • Are there other paths (e.g., /synthesize)?

2. Is there a known issue with Docker networking?

   • Why does curl from the host work, but not from the Open WebUI container?

3. Does Chatterbox expect specific headers or payload formats?

   • The 404 suggests the endpoint exists but rejects the request.

---

Request for Help

If anyone has successfully integrated Chatterbox-TTS with Open WebUI (or another frontend), I’d appreciate guidance on:

• The correct API endpoint/path.
• Docker networking tweaks (e.g., custom networks, hostnames).
• Debugging steps to trace the 404 error.

Thanks in advance!

[Ithrial]

I've had it working good for a while with my OWUI implementation (currently on 0.8.12).

TTS engine is OpenAI. TTS Engine is http://ip-address:port/v1 - take out the /audio/speech
TTS Voice is the actual file name of the voice that you're cloning. My api key is just nokeyneeded - tts model I have is tts-1-hd

[connectnet]

Thank you Ithrial. But when I select "OpenAi" as TTS Model than openwebui adds automatically "audio/speech".

[Ithrial]

This is what my TTS section looks like in OWUI. Have you confirmed that your OWUI instance can reach 192.168.77.113? Can it ping it? Can you get to the Chatterbox web gui?

[connectnet]

Yes. IP is reachable from OWUI and Chatterbox web gui works fine. But it doesnt connect.

[Ithrial]

The only other thing I can think of is your OWUI instance might be messed up - what version are you on? Have you updated recently? Sorry for the rudimentary IT questions but not sure what else it could be.

[connectnet]

OWUI vers. 0.8.12 installation works fine. I tested OWUI from an other installation but nothing changed. Than I separated the chatterbox installation to CPU to avoid a GPU conflict nothing helps.