Testing an AI API from a country where the official card checkout keeps failing

Disclosure and availability

DaoXE is a multi-model, multi-protocol API gateway we operate (OpenAI Chat Completions, OpenAI Responses, Anthropic Messages / Claude protocol, and image-generation-compatible endpoints - not OpenAI-only, not Claude-only). It is not available in mainland China. This article is for developers in regions allowed by the service terms. The checklist works for any OpenAI-compatible gateway, not just DaoXE.

If you build software from Vietnam, Indonesia, Turkey, or a dozen other places, you know a failure mode that rarely shows up in English tutorials: the model works fine, but the billing page doesn't. An international card gets declined, a region isn't in the dropdown, or a subscription won't activate. The code is not the problem. The checkout is.

This post is the practical checklist I use when the goal is "get a real request through," separate from "argue with a payment form." It assumes you route through a gateway that already handles billing in a way you can actually complete, and it focuses on proving the integration is correct.

1. Separate the two failures

Write them down as two different problems:

• Access failure: you cannot get a working API key / balance at all.
• Integration failure: you have a key, but requests fail.

Most "the API is broken" reports are actually one of these wearing the other's clothes. A gateway that accepts a payment method you can complete solves the first. This checklist solves the second.

2. Prove the key with one tiny request

Do not start inside your app. Start with the smallest possible call. Discover a model first - do not paste a model name from a blog:

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

# what can this account actually call?
curl --fail-with-body --show-error --silent \
  -H "Authorization: Bearer $DAOXE_API_KEY" \
  "$DAOXE_BASE_URL/models"

Then one tiny Chat Completions request (keep max_tokens small; it may be billed):

export DAOXE_MODEL="paste_exact_id_from_the_list"

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\":\"Reply with OK.\"}]}" \
  "$DAOXE_BASE_URL/chat/completions"

• 200 + tiny completion → billing and access are fine; any remaining failure is in your app config.
• 401/403 → key/balance problem, still an access issue - fix it before touching code.

3. Match the protocol to your client

A multi-protocol gateway can speak more than one dialect. Your client usually speaks exactly one:

If you configure the wrong dialect, you get auth or 404 errors that look like a billing problem but are not.

4. Keep the money side small while testing

Because the whole point is that checkout is painful where you are, do not waste balance during setup:

• cap max_tokens at 8 during smoke tests
• disable retries so one failure is one request, not five
• test one client before wiring it into your whole stack
• refresh model IDs from /v1/models instead of shipping a stale hardcoded list

5. Claude Code specifically

If your tool is Claude Code, you point it at the gateway with two environment variables (host root, not /v1):

export ANTHROPIC_BASE_URL="https://daoxe.com"
export ANTHROPIC_AUTH_TOKEN="your_api_key"
claude

Full native setup, including the ANTHROPIC_AUTH_TOKEN vs ANTHROPIC_API_KEY gotcha, is here: CLAUDE_CODE.md.

What this is not

• not advice to bypass any provider's or government's rules
• not a claim that every model is always available
• not a benchmark or quality ranking

It is a way to stop conflating "I can't complete the checkout" with "the API doesn't work for me." They are different problems and only one of them is in your code.

Links

• Client setup (Cline / Roo / Continue + protocol paths): CLIENT_SETUP.md
• Public examples + low-cost benchmark: DaoXE-AI
• Homepage (tracked): daoxe.com