DEV Community

Adela for BetterToken.ai

Posted on Edited on Originally published at bettertoken.ai

Neural Network APIs: Protocols, Keys, and Your First Request

Before connecting a neural network API, identify the contract your client expects: OpenAI-compatible or Anthropic-compatible. Then take the Base URL from that provider’s current documentation, keep the API key outside your code, and make one small request. A saved settings form is not proof of a working connection: check the HTTP status, returned model, usage fields when available, and the provider’s usage record.

BetterToken is one API-access option with separate OpenAI-compatible and Anthropic-compatible interfaces. Use your own account and API Key, then make a minimal request. When connecting to the BetterToken API Endpoint from Russia, no VPN is required; this does not apply to third-party tool sites, accounts, or downloads.

API access, a web subscription, and another person’s account are different

API access lets an application send an HTTP request to a provider endpoint using a key. A web subscription grants access to a particular product interface and does not automatically give the same API balance or API configuration.

Do not put someone else’s account or key into a project as a shortcut. It creates an avoidable security and ownership problem. Use an account and key that your team can revoke and rotate, then follow the documentation for the provider you selected.

Choose the protocol from the client contract

Read the documentation for the SDK, CLI, or application that will send the request. The client contract—not the model’s marketing name—decides the protocol.

Use an OpenAI-compatible configuration when the client documents the OpenAI SDK, Chat Completions, Responses, or a setting such as OPENAI_BASE_URL. Use an Anthropic-compatible configuration when it constructs Messages requests and documents ANTHROPIC_BASE_URL or x-api-key authentication.

OpenAI-compatible does not mean every OpenAI resource is implemented by every provider. If the tool expects Responses, use the Responses request shape documented for that provider; do not send it the Chat Completions template below. Likewise, an Anthropic-compatible tool needs the Messages contract, not a Bearer-token request copied from an OpenAI example.

Need to check the protocol and first-request fields? Open the API configuration reference

Keep the Base URL separate from the raw request path

A tool’s Base URL is the root it uses before appending its own resource path. A direct curl request uses the complete path. Treat them as different inputs.

For an OpenAI-compatible client, a provider may document a Base URL and a Chat Completions path like this:

Base URL: https://api.example.com/v1
Raw request path: https://api.example.com/v1/chat/completions
Enter fullscreen mode Exit fullscreen mode

For an Anthropic-compatible client, the corresponding pattern may be:

Base URL: https://api.example.com
Raw Messages path: https://api.example.com/v1/messages
Enter fullscreen mode Exit fullscreen mode

These are shapes, not values to paste into a real configuration. Copy the actual Base URL and raw path only from the selected provider’s documentation. If a field is named Base URL, do not paste /chat/completions or /v1/messages into it unless the tool explicitly requires the full path. Otherwise the client can append the resource twice and return 404.

Store the key as a secret

For a local test, use environment variables with placeholders:

export API_KEY="your_api_key_here"
export MODEL_ID="your_current_model_id"
export OPENAI_BASE_URL="https://api.example.com/v1"
export ANTHROPIC_BASE_URL="https://api.example.com"
Enter fullscreen mode Exit fullscreen mode

Never put a real key in source code, .env.example, an issue, a prompt, a screenshot, or a command that will be retained in shared shell history. For production, use the secret-management mechanism of your deployment platform. Keep the OpenAI-compatible and Anthropic-compatible settings separate so that a correct key is not sent with the wrong authentication header or URL.

Send a minimal OpenAI-compatible request

Use this only when your chosen provider documents the Chat Completions contract. It is a template: replace the placeholder Base URL and Model ID with values from that provider.

curl "$OPENAI_BASE_URL/chat/completions" \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "'"$MODEL_ID"'",
    "messages": [{"role": "user", "content": "Reply with API_OK"}],
    "max_tokens": 16
  }'
Enter fullscreen mode Exit fullscreen mode

The OpenAI Chat Completions contract uses a Bearer authorization header and the /chat/completions resource. Do not enable -v in logs that other people can read, because verbose output can expose request headers.

Send a minimal Anthropic-compatible request

Use this only when the selected provider documents the Anthropic Messages contract. The API key header, version header, and request body are different from the OpenAI-compatible example.

curl "$ANTHROPIC_BASE_URL/v1/messages" \
  -H "x-api-key: $API_KEY" \
  -H "anthropic-version: CURRENT_SUPPORTED_VERSION" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "'"$MODEL_ID"'",
    "max_tokens": 16,
    "messages": [{"role": "user", "content": "Reply with API_OK"}]
  }'
Enter fullscreen mode Exit fullscreen mode

CURRENT_SUPPORTED_VERSION is deliberately a placeholder. Obtain the supported version and any additional headers from the current documentation of the provider you are calling; do not revive a version value from an old article.

Verify the response instead of trusting the settings screen

Treat the first call as successful only when several signals agree:

  • the HTTP status is successful;
  • the response reports the expected Model ID or a documented model mapping;
  • the response includes usage when that endpoint promises usage fields;
  • the provider’s usage or billing record shows the request with the expected status and charge.

Model availability, Model IDs, and prices are dynamic. Check the current provider catalog and price page before calculating a budget. Do not copy a price, a cache discount, a compatibility claim, or an availability claim from a different model or an older guide.

Diagnose the first failures

401

Check the key, stray spaces, and the authentication method. A Bearer header and x-api-key are not interchangeable; use the one specified by the selected protocol.

404

Compare the tool’s Base URL with the raw request path. A duplicate /v1 or a repeated resource segment such as /chat/completions is a common configuration error.

model not found

Copy the current Model ID from the selected provider and check that the key and protocol are allowed to use it. A marketing name can differ from the ID used by an API.

Timeout or TLS error

Separate local networking, proxy, and certificate failures from an HTTP response first. A short direct request can show whether the provider endpoint is reachable. Do not disable TLS verification as a permanent workaround.

Add complexity only after the first request works

The useful order is: identify the client contract, store the key as a secret, configure the correct Base URL, send one short request, and inspect the response and usage record. Add streaming, tools, long context, or an agent workflow only after that. Each layer has its own event format and failure modes, so adding them all at once makes the first error harder to diagnose.

Sources


Originally published on the BetterToken blog.

BetterToken provides pay-as-you-go access to AI model APIs through
OpenAI-compatible and Anthropic-compatible endpoints — useful if you are wiring
Claude Code, Codex, or your own tooling to a custom base URL.
See the docs to get started.

Top comments (0)