qwen2API: A Self-Hosted Go Gateway That Converts Qwen Web into OpenAI, Anthropic, and Gemini APIs

What qwen2API Does and Who It Targets

qwen2API converts the Qwen web application into a local API gateway. Rather than calling an official API endpoint, it logs into Qwen's web interface through browser automation, submits requests, and returns the response through one of three protocol adapters: OpenAI-compatible chat completions and responses, Anthropic-compatible messages, or Gemini-compatible content generation. Any client that can speak one of those protocols, such as an OpenAI SDK, Claude Code, Codex, or a Gemini-compatible tool, can point to qwen2API and treat it as its model backend.

The intended user is a developer who has Qwen web accounts but does not have or want an official Qwen API key, and who needs to integrate Qwen's capabilities into tooling that expects a standard API interface. The v2.0 release (Go backend plus React WebUI) is the current mainline. Version 1.0, which used Python and FastAPI, is described in the README as a legacy version kept only as historical context.

Three Protocol Adapters and the Multi-Account Pool

The feature table in the README lists the specific endpoint paths exposed by each adapter. The OpenAI-compatible layer covers /v1/chat/completions, /v1/responses, /v1/models, /v1/files, /v1/images/generations, and /v1/videos/generations. The Anthropic-compatible layer provides /v1/messages, /anthropic/v1/messages, and /v1/messages/count_tokens. The Gemini-compatible layer provides /v1beta/models/{model}:generateContent and /v1beta/models/{model}:streamGenerateContent.

Underneath these adapters is an account pool that rotates across multiple Qwen web accounts. The pool tracks per-account concurrency and maintains separate cooldown timers for chat, image, and video workloads. The .env.example shows variables such as MAX_INFLIGHT_PER_ACCOUNT, RATE_LIMIT_BASE_COOLDOWN (default 600 seconds), and RATE_LIMIT_MAX_COOLDOWN (default 3600 seconds). These parameters shape how aggressively the service retries after Qwen rate-limits a particular account.

The Dockerfile reveals that qwen2API bundles Playwright and a set of Chromium system dependencies to drive the Qwen web interface. This is the same architecture as other Qwen or Gemini scraper gateways: requests arrive through the API layer, the Go router dispatches them to the browser pool, and the browser submits them to the Qwen web application.

Deploying qwen2API with Docker Compose

The recommended deployment path uses the published Docker Hub image. Create a working directory, add data and log subdirectories, and write a minimal .env file:

mkdir qwen2api
cd qwen2api
mkdir -p data logs

Set the required variables. ADMIN_KEY must be a strong private value:

HOST_PORT=7860
HOST_DATA_DIR=./data
HOST_LOGS_DIR=./logs
ADMIN_KEY=replace-with-your-own-strong-random-key

Create a docker-compose.yml that mounts the data and logs directories into the container:

services:
  qwen2api:
    image: ${QWEN2API_IMAGE:-yujunzhixue/qwen2api:latest}
    container_name: qwen2api
    restart: unless-stopped
    init: true
    env_file:
      - .env
    ports:
      - "${HOST_PORT:-7860}:${PORT:-7860}"
    volumes:
      - ${HOST_DATA_DIR:-./data}:/app/data
      - ${HOST_LOGS_DIR:-./logs}:/app/logs
    shm_size: "512m"
    healthcheck:
      test: ["CMD-SHELL", "curl -fsS http://127.0.0.1:${PORT:-7860}/healthz || exit 1"]
      interval: 30s
      timeout: 10s
      start_period: 120s
      retries: 3

Start the service:

docker compose pull
docker compose up -d
docker compose logs -f qwen2api

The WebUI is then accessible at http://127.0.0.1:7860. The health check endpoint is at /healthz and the keepalive probe at /keepalive. The README notes that accounts.json and api_keys.json are handled internally by the image; the volume mapping is only needed to persist data across container restarts and upgrades.

Configuration Variables and the WebUI Management Panel

The WebUI exposed at port 7860 provides account management (adding and removing Qwen web accounts), API key management (creating and removing downstream keys), runtime configuration, and test endpoints for chat, image, and video.

The README distinguishes between persistent configuration and runtime-only configuration. ADMIN_KEY is the management key for the WebUI and admin APIs and must be set to a strong private value. Downstream API keys injected as QWEN_API_KEY, QWEN_API_KEYS, or QWEN_API_KEY_N environment variables are accepted at runtime but are not written to data/api_keys.json and cannot be deleted from the WebUI, making them suitable for secrets management systems that inject environment variables at container startup. Similarly, QWEN_ACCOUNT_N environment variables inject Qwen accounts at runtime without persisting them to data/accounts.json.

The .env.example lists several additional tuning parameters: BROWSER_POOL_SIZE (default 1), MAX_INFLIGHT_PER_ACCOUNT (default 2), MAX_RETRIES (default 3), and TOOL_RECOVERY_MAX_ATTEMPTS (default 4, clamped to 1 to 8). The KEEPALIVE_URL and KEEPALIVE_INTERVAL variables configure an optional background probe that keeps Qwen web sessions alive between requests.

Building from Source for Development

The development requirements are Go 1.26, Node.js 20 or later, npm, and Docker for container builds. To start both the Go backend and React frontend together in one step:

go run start-all.go

For backend-only development:

cd backend
go run .

For frontend development with hot reload:

cd frontend
npm ci
npm run dev

The production frontend build outputs static assets:

cd frontend
npm run build

The Dockerfile shows a multi-stage build: a Node.js stage builds the React WebUI assets, a Go stage compiles the backend binary with CGO disabled for a static binary, and the runtime stage is debian:bookworm-slim with Playwright browser dependencies installed. The contribution rules in the README ask developers to keep Docker data paths container-internal as /app/data and /app/logs, to control host paths through compose volume mappings instead of hard-coded workspace paths, and to not commit the data/, logs/, or .env directories.

The Browser Automation Risk and When to Use a Direct API Instead

qwen2API automates the Qwen web interface through Playwright. Every change to Qwen's DOM structure, login flow, or request format can break the gateway without warning. This is the defining limitation of web scraper gateways: there is no versioned contract between the scraper and the web application it drives.

Alibaba Cloud's official DashScope platform provides the Qwen API with documented endpoint schemas, versioned models, and explicit deprecation policies. Using DashScope requires an API key and incurs usage costs, but it provides a stable interface that does not depend on Qwen's web UI staying unchanged. Developers building services that need consistent uptime and predictable failure modes should use DashScope rather than qwen2API.

qwen2API is better suited to personal use, experimentation, and situations where access to Qwen web accounts is available but an official API key is not. The multi-account pool and cooldown management reduce the risk of a single account being rate-limited, but they do not eliminate the underlying dependency on browser automation against a web interface that can change unilaterally.

Maintenance Status and License

The repository is not archived. The last push was on 2026-06-13. The project has no GitHub releases; distribution is through Docker Hub at yujunzhixue/qwen2api. A Telegram group is linked at t.me/qwen2api for user community discussion.

The repository does not declare a recognized license identifier. The License field in the repository metadata is listed as unknown, and no LICENSE file is documented in the top-level entries. The top-level entries are .dockerignore, .editorconfig, .env.example, .github/, .gitignore, Dockerfile, README.md, README_CN.md, README_EN.md, backend/, docker-compose.build.yml, docker-compose.yml, frontend/, and start-all.go. Teams that need to verify licensing before incorporating qwen2API into a deployment should inspect the repository directly for any license terms not reflected in the metadata. Without a recognized open-source license, the default legal position in most jurisdictions is that the author retains all rights, and redistribution or modification may not be permitted without explicit permission.

Editorial conclusion

qwen2API suits developers who want to use Qwen's web capabilities through standard API protocols without an official Qwen API key, and who are comfortable operating a service that depends on browser automation against Qwen's web interface. It is not a replacement for a stable, versioned API contract: the Qwen web UI can change without notice and has done so before. Teams with production reliability requirements should use Alibaba Cloud's official DashScope Qwen API instead. Before deploying, confirm you have one or more Qwen web accounts to add to the pool, and set a strong ADMIN_KEY before exposing the service to any network.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. YuJunZhiXue/qwen2API on GitHub