How to Connect OpenAI-Compatible, Anthropic, and Azure OpenAI APIs

Fasten Share can publish a local or online model API as a producer node, but APIs are not interchangeable simply because they all use HTTP and JSON. OpenAI Chat Completions, OpenAI Responses, Anthropic Messages, and Azure OpenAI differ in paths, authentication headers, model fields, and version parameters.

Reliable setup begins by identifying the real backend protocol and separating the base URL, version prefix, model, and credential. Repeatedly changing fields until one health check happens to pass creates a node that is difficult to maintain.

Collect five facts before configuring the client

Use the backend’s official documentation or control panel to confirm:

1. Base URL, usually a scheme and host such as https://api.example.com.
2. Protocol, such as OpenAI Chat Completions, Responses, Anthropic, or Azure OpenAI.
3. Version path or API version, such as /v1 or an Azure api-version.
4. Actual model ID, not merely a display label in a dashboard.
5. Access credential, ideally a least-privilege API key created for this sharing purpose.

For a third-party compatibility service, also verify that its terms allow proxying, forwarding, or third-party access. Technical compatibility is not permission to share.

Test the endpoint directly

OpenAI Chat Completions style

curl https://api.example.com/v1/chat/completions \
  -H "Authorization: Bearer UPSTREAM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model":"your-model-id",
    "messages":[{"role":"user","content":"reply with OK"}],
    "stream":false
  }'

OpenAI Responses style

curl https://api.example.com/v1/responses \
  -H "Authorization: Bearer UPSTREAM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"your-model-id","input":"reply with OK"}'

Anthropic Messages style

curl https://api.example.com/v1/messages \
  -H "x-api-key: UPSTREAM_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{
    "model":"your-model-id",
    "max_tokens":32,
    "messages":[{"role":"user","content":"reply with OK"}]
  }'

The domain, model, and version above are placeholders. Replace them with the backend’s real values. Azure OpenAI also requires a deployment name and API version; validate the exact parameters supplied by the Azure deployment before continuing.

Separate the base URL and version prefix

Fasten Share combines a base URL, version prefix, and consumer request path. A frequent mistake is putting /v1 in both the base URL and the version-prefix field, producing a path such as /v1/v1/....

A typical split is:

Setting	Recommended shape
Base URL	https://api.example.com
Version prefix	/v1
Request path	/chat/completions, /responses, or /messages

Some services live under an additional gateway path such as https://api.example.com/ai-gateway. Whether that path belongs in the base URL depends on the service. Use the client’s final URL preview and a direct request rather than removing required path segments by assumption.

Choose the correct producer protocol

• Select the OpenAI protocol for a Chat Completions backend.
• Select openai-response for a native Responses backend.
• Select Anthropic for an Anthropic Messages backend.
• Use the Azure OpenAI protocol and provide its deployment and API-version details.
• If the client offers Chat Completions-to-Responses conversion, enable it only after understanding its limits.

Protocol conversion is not a complete clone of the upstream API. Stateful Responses sessions, hosted tools, background mode, Responses WebSocket, and some tool behavior may not be available through a converted node. A consumer who needs those features should choose a native protocol node.

Configure credentials, models, and concurrency

The producer client stores the upstream API key locally and injects it into calls to the backend. Create a dedicated key with the smallest useful permission and budget rather than reusing an administrator credential. Consumers use their own Fasten Share API keys and never receive the upstream key.

Publish exact backend model IDs. Health checking needs a real model, so keep the first configured model stable and available. Maximum concurrency should stay below the upstream account’s rate limit and your self-hosted service capacity. If you see 429, long queues, or timeouts, reduce concurrency before changing unrelated fields.

Diagnose health-check failures in order

1. Send a direct request with the same URL, protocol, model, and key.
2. Check for a duplicated base-path or version prefix.
3. Confirm that the selected protocol matches the request shape.
4. Verify the model ID, Azure deployment name, and API version.
5. Check whitespace, key permissions, balance, and upstream rate limits.
6. Inspect proxy, DNS, TLS certificate, and network access from the producer machine.
7. Only then inspect the Fasten Share producer connection.

Finding the first failing boundary is more reliable than editing several fields at once.

Security checklist before publishing

• Use an official or trusted HTTPS upstream endpoint.
• Keep upstream credentials out of screenshots, tutorials, logs, and Git repositories.
• Create a dedicated, least-privilege, revocable sharing key.
• Confirm that the upstream permits your forwarding and commercial-use pattern.
• Set upstream quota alerts and conservative Fasten Share concurrency.
• Complete one end-to-end request from the consumer workflow.
• Revisit model names, API versions, and upstream terms periodically.

For a CLIProxyAPI backend serving Codex or Claude scenarios, continue with Connect CLIProxyAPI to Fasten Share. Local Ollama users can use the Ollama and local LLM guide.