DEV Community

Seven
Seven

Posted on

OPENAI_API_KEY vs DAOXE_API_KEY: which env name your client actually reads

#tutorial #api #webdev #ai

Disclosure and availability: DaoXE is a multi-model multi-protocol API gateway we operate. It is not available in mainland China. This article is for developers in regions allowed by the service terms.

I had a green curl.

The agent still said “unauthorized.”

The key was fine. The env name was wrong for that client.

This post is the short map I use when base URL works but the tool never picks up the secret.

Series

  1. Smoke test
  2. Multiprotocol
  3. Client setup
  4. curl OK, IDE fails
  5. Claude protocol
  6. models.dev + /models
  7. Agent pre-flight
  8. This post: env var names

Two different secrets

Kind Example Means
Vendor-shaped OPENAI_API_KEY many OpenAI SDKs / tools default here
Gateway-shaped DAOXE_API_KEY docs/catalog for DaoXE; some clients allow custom envar
Anthropic-shaped ANTHROPIC_API_KEY / x-api-key field Messages clients

Curl does not care about the name:

export DAOXE_API_KEY="your_api_key"
curl -H "Authorization: Bearer $DAOXE_API_KEY" https://daoxe.com/v1/models
Enter fullscreen mode Exit fullscreen mode

The agent process might only read OPENAI_API_KEY unless you configure a custom provider field.

Common patterns

A. OpenAI SDK with custom base 

export OPENAI_API_KEY="your_gateway_key"   # SDK default name
export OPENAI_BASE_URL="https://daoxe.com/v1"
Enter fullscreen mode Exit fullscreen mode

Some libraries use OPENAI_API_BASE instead of OPENAI_BASE_URL. Check the client docs once.

B. Gateway-native name (when the tool supports it) 

export DAOXE_API_KEY="your_gateway_key"
# base often hard-set to https://daoxe.com/v1 in UI or catalog
Enter fullscreen mode Exit fullscreen mode

models.dev lists DaoXE with env DAOXE_API_KEY and api=https://daoxe.com/v1. Catalog-driven tools may expect that exact name.

C. Anthropic Messages clients

Bearer-only Chat Completions success does not prove Messages works. Those clients often need:

  • x-api-key
  • anthropic-version
  • POST /v1/messages

Failure table

Symptom Likely cause Fix
curl 200, agent 401 agent reads different env set the name that client documents
works in shell, fails in IDE IDE not inheriting shell env set key in IDE provider UI / launch env
works for OpenAI path, fails Claude path wrong protocol + auth style Messages headers + /v1/messages
teammate fails with same README account-scoped models / different secret store each person lists /v1/models

Minimal verification order

  1. curl with explicit -H "Authorization: Bearer …" (no env ambiguity)
  2. export the client’s preferred key name
  3. restart the agent process so it reloads env
  4. one tiny Chat Completions call from that same process path

Public setup notes:

Soft CTA

If you want the product side:

https://daoxe.com/?utm_source=devto&utm_medium=organic&utm_campaign=global_launch_env

Comment with client name + which env names it documents. Do not paste keys.

Top comments (0)