DEV Community

Seven
Seven

Posted on

One gateway, three protocols: Chat Completions, Responses, and Anthropic Messages

#webdev #ai #tutorial #api

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

Many multi-model gateways get described as "OpenAI-compatible". That phrase is useful, but incomplete.

If you only test Chat Completions, you can miss the real shape of the product:

  • some clients speak OpenAI Chat Completions
  • some agent tools prefer OpenAI Responses
  • some coding tools prefer Anthropic Messages
  • model availability is often account-scoped, not a permanent public list

This post is a practical checklist for validating a multi-protocol gateway without turning the article into a feature brochure.

1. Name the protocols explicitly

When I evaluate a gateway, I write down the protocols I care about first:

Protocol Typical clients What I verify
OpenAI Chat Completions SDKs, many chat UIs /v1/chat/completions
OpenAI Responses newer agent stacks /v1/responses if exposed
Anthropic Messages Claude-oriented tools /v1/messages if exposed

If a product only documents Chat Completions, that is fine — but I stop calling it multi-protocol in my own notes.

For DaoXE, the public base URL is:

https://daoxe.com/v1
Enter fullscreen mode Exit fullscreen mode

I treat that as the OpenAI-compatible root for Chat Completions and model discovery, then check whether other protocol endpoints are documented and reachable for my account.

2. Discover models from the current account

Do not hardcode model names from a blog post.

export DAOXE_API_KEY="your_api_key"
export DAOXE_BASE_URL="https://daoxe.com/v1"

curl --fail-with-body --show-error --silent \
  -H "Authorization: Bearer $DAOXE_API_KEY" \
  "$DAOXE_BASE_URL/models"
Enter fullscreen mode Exit fullscreen mode

What I look for:

  • HTTP 401/403 when the key is wrong
  • HTTP 200 with model IDs when the key is valid
  • IDs I can copy exactly into the next request

If /models is account-scoped, that is a feature, not a bug. It means your integration should refresh models instead of shipping a stale static list.

3. Run one Chat Completions smoke request

Keep output tiny. You want connectivity, not a demo essay.

export DAOXE_MODEL="paste_exact_model_id_here"

curl --fail-with-body --show-error --silent \
  -H "Authorization: Bearer $DAOXE_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{
    \"model\": \"$DAOXE_MODEL\",
    \"max_tokens\": 8,
    \"messages\": [{\"role\":\"user\",\"content\":\"ping\"}]
  }" \
  "$DAOXE_BASE_URL/chat/completions"
Enter fullscreen mode Exit fullscreen mode

A useful pass/fail is simple:

  • Pass: HTTP 200, a model field, tiny completion or usage metadata
  • Fail: auth error, model-not-found, timeout, HTML error page

I keep retries disabled during smoke tests so a failure is easy to attribute.

4. Check the other protocols only if your clients need them

If your stack never uses Anthropic Messages or Responses, do not expand scope yet.

If it does, verify the exact endpoint your client will call. For example, some tools expect Anthropic-style headers and /v1/messages, while others only rewrite base_url for OpenAI SDKs.

The important part is not claiming every protocol is identical. The important part is knowing which protocol each client actually speaks.

5. Keep the client config boring

For OpenAI-compatible clients, the boring setup is usually best:

  • Base URL: https://daoxe.com/v1
  • API key: from the dashboard
  • Model: exact ID from the current account catalog

I keep a public, auditable setup page here:

DaoXE client setup

and low-cost smoke/compare examples here:

DaoXE-AI examples

What this is not

  • not a latency benchmark
  • not a model quality ranking
  • not a claim that every model family is always available
  • not a claim that every client supports every protocol path

It is a way to stop an integration review from collapsing into "does OpenAI Chat Completions work once?"

Closing checklist

  1. List the protocols your real clients use.
  2. Discover model IDs from the current account.
  3. Smoke-test one tiny Chat Completions request.
  4. Only then verify Responses / Anthropic Messages if needed.
  5. Keep keys out of source control.

If you want a starting point, the public examples repository above is intentionally small so you can audit every request path.

Related

If you try the checklist against another gateway, keep the same order: protocols first, account models second, one tiny generation third.

Top comments (1)

Collapse
 
seven7763 profile image
Seven •

If you only need one boring OpenAI Compatible base URL for coding tools, start with the smoke-test post first:

dev.to/seven7763/the-3-step-smoke-...

Client-specific wiring (Cline, Continue, Roo Code, and similar) is here:

dev.to/seven7763/how-i-configure-c...

Living matrix: github.com/seven7763/DaoXE-AI/blob...

Note: many IDE clients only speak Chat Completions even when the gateway also exposes Responses and Anthropic Messages. Match the protocol to the client.