How to Connect Coze to an OpenAI Responses API Provider

If you want a private, browser-based AI workspace without rebuilding chat, user management, and model selection from scratch, Open WebUI plus an OpenAI-compatible endpoint is a practical place to start.

This guide walks through a small but production-minded setup: run Open WebUI in Docker, point it at Ace Data Cloud, verify the connection outside the UI, and avoid the configuration mistakes that tend to waste the most time.

What you are building

The architecture is deliberately simple. Open WebUI provides the browser interface, local conversation storage, user roles, and optional knowledge-base features. Ace Data Cloud sits behind it as an OpenAI-compatible model endpoint.

The important connection values are:

• Base URL: https://api.acedata.cloud/v1
• Chat endpoint: POST https://api.acedata.cloud/v1/chat/completions
• Authentication header: Authorization: Bearer {token}
• Model discovery: GET https://api.acedata.cloud/v1/models

That final endpoint matters more than it may seem. Model catalogs change, so it is safer to let Open WebUI load the current list than to copy a model ID from an old setup note.

There is also a path detail worth understanding up front. The base URL must match the route family you intend to use. https://api.acedata.cloud/v1 correctly produces /v1/chat/completions. The alternative base https://api.acedata.cloud/openai is also available, but appending /v1 to that route creates https://api.acedata.cloud/openai/v1/chat/completions, which does not exist and returns 404.

Start Open WebUI with Docker

Create an API token in your Ace Data Cloud application, then run the container below. Keep the token out of shell history in a real deployment—for example, load it from an environment file or secret manager rather than committing it to a repository.

docker run -d \
  --name open-webui \
  -p 3000:8080 \
  -e WEBUI_SECRET_KEY=$(openssl rand -base64 32) \
  -e OPENAI_API_BASE_URL=https://api.acedata.cloud/v1 \
  -e OPENAI_API_KEY={token} \
  -v open-webui:/app/backend/data \
  ghcr.io/open-webui/open-webui:main

Each setting has a narrow job:

• OPENAI_API_BASE_URL tells the client where the compatible API begins. Keep the trailing /v1 in this configuration.
• OPENAI_API_KEY carries your Ace Data Cloud token.
• WEBUI_SECRET_KEY protects web sessions; the command generates a fresh value.
• -v open-webui:/app/backend/data persists conversations and user data across container restarts.

Open http://your-server-IP:3000 after the container starts. The first account registered becomes the administrator, so do the initial signup yourself rather than leaving a fresh instance exposed.

Inside Open WebUI, go to Admin Panel → Settings → Connections and use Verify Connection. Then open Settings → Models to filter or pin the models you actually want users to see. You can also add the same Base URL and API key directly through the Connections interface instead of environment variables; Open WebUI will call /models to populate the catalog.

Verify the API before debugging the UI

When a chat interface says only “connection failed,” it hides too many possible causes: a malformed base URL, an invalid token, an unavailable model, or a network problem. A direct request separates the API layer from the UI layer.

First retrieve the current model list, choose an ID returned there, and replace MODEL_ID below:

curl -X POST 'https://api.acedata.cloud/v1/chat/completions' \
  -H 'Authorization: Bearer {token}' \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "MODEL_ID",
    "messages": [
      {"role": "user", "content": "ping"}
    ]
  }'

A successful request returns an OpenAI-compatible chat.completion object. If you receive HTTP 403 used_up, the token is valid but its balance is insufficient. If you receive a 404, inspect the URL first—especially the common accidental /openai/v1 combination.

This is the debugging order I prefer as a builder: prove the token and route with curl, verify the connection in the admin panel, and only then investigate model or browser behavior. It avoids changing several layers at once.

Make the setup safer for a small team

Open WebUI supports multiple users, but a public registration screen can also turn into unplanned API usage. In Admin Panel → Users, set the default user role to pending so each new account requires review. Available roles include Pending, User, and Admin.

For document chat, Open WebUI uses ChromaDB for vector storage by default. The documented embedding option is text-embedding-3-large. Original documents remain on your server, while matched segments are sent to the model during retrieval. If uploaded documents do not produce chat results, check the embedding model in the RAG settings before assuming the chat endpoint is broken.

If you place nginx in front of the container, add:

proxy_buffering off;
client_max_body_size 100M;

The first setting avoids buffered streaming behavior, while the second allows larger uploads. And do not skip the Docker volume: without /app/backend/data persistence, a container replacement can take conversations and local user state with it.

A short troubleshooting checklist

Before changing the deployment, check these in order:

1. Is the base URL exactly https://api.acedata.cloud/v1?
2. Does a direct request to /v1/chat/completions work with the same token?
3. Is the selected model present in the current /v1/models response?
4. Is the persistent volume mounted?
5. For RAG, is text-embedding-3-large selected as the embedding model?
6. For team access, are new users held in the pending role?

The useful part of an OpenAI-compatible interface is not that every client becomes identical; it is that you can test one clean HTTP boundary and then choose the interface that fits your team. Keep that boundary observable, start with the smallest deployment, and use the full Ace Data Cloud Open WebUI setup reference when you need to revisit the exact connection rules.