Skip to main content
API7.ai Logo

Other OpenAI-Compatible Providers

Many public model providers expose an OpenAI-compatible API. AISIX can connect to these providers with the openai adapter when they accept OpenAI chat-completions requests.

When a provider has a dedicated setup listed under Provider Upstreams, follow that path instead. The configuration below applies to another public OpenAI-compatible provider and uses Fireworks AI as a verified example.

For private or self-hosted OpenAI-compatible servers, use Bring Your Own Endpoint instead.

Prerequisites​

The following examples use a self-hosted AISIX gateway. Before configuring the upstream, prepare the following:

  • A running AISIX gateway with the Admin API and proxy API available. Commands use the Quickstart listener addresses; substitute your configured addresses if needed.
  • The admin key from the gateway config.yaml.
  • An API key for the public OpenAI-compatible provider.

Configure the Provider Upstream​

Create a provider key, model alias, and caller API key for the provider-backed chat-completions route. The examples use Fireworks AI, the API root https://api.fireworks.ai/inference/v1, and the model ID accounts/fireworks/models/deepseek-v3p1. For another compatible provider, replace these values with those from the provider's API reference.

Create a Provider Key​

Create the provider key for the OpenAI-compatible provider endpoint:

# Replace with your values
export AISIX_ADMIN_KEY="YOUR_ADMIN_KEY"
export PROVIDER_API_KEY="YOUR_PROVIDER_API_KEY"

curl -sS -X POST "http://127.0.0.1:3001/admin/v1/provider_keys" \
  -H "Authorization: Bearer ${AISIX_ADMIN_KEY}" \
  -H "Content-Type: application/json" \
  --data-binary @- <<EOF
  {
    "display_name": "fireworks-prod",
    "provider": "fireworks",
    "adapter": "openai",
    "secret": "${PROVIDER_API_KEY}",
    "api_base": "https://api.fireworks.ai/inference/v1"
  }
EOF

❶ provider identifies the public provider.

❷ adapter selects the OpenAI-compatible upstream format.

❸ secret stores the provider API key.

❹ api_base points to the provider's OpenAI-compatible API root.

Copy the returned provider key ID. AISIX appends the endpoint path to api_base, so include provider-specific prefixes such as /v1 or /openai/v1 when required. Do not rely on AISIX to infer a public provider URL.

Provider key secrets follow the credential-handling behavior described in Provider Credentials.

Create a Model​

Map a caller-facing alias to the provider's model ID:

# Replace with your values
export PROVIDER_KEY_ID="YOUR_PROVIDER_KEY_ID"

curl -sS -X POST "http://127.0.0.1:3001/admin/v1/models" \
  -H "Authorization: Bearer ${AISIX_ADMIN_KEY}" \
  -H "Content-Type: application/json" \
  --data-binary @- <<EOF
  {
    "display_name": "fireworks-deepseek-prod",
    "provider": "fireworks",
    "model_name": "accounts/fireworks/models/deepseek-v3p1",
    "provider_key_id": "${PROVIDER_KEY_ID}"
  }
EOF

❶ display_name is the alias callers send in model.

❷ model_name is the model ID expected by the provider.

❸ provider_key_id attaches the model alias to the provider key you created.

Add a cost block only when you need budget accounting or usage reports to calculate token cost for this alias. See Model Aliases.

Create a Caller API Key​

Choose the caller API key value that the application will send to AISIX, then hash it for the admin resource:

# Replace with your values
export AISIX_API_KEY="YOUR_CALLER_API_KEY"

CALLER_KEY_HASH=$(printf '%s' "${AISIX_API_KEY}" | shasum -a 256 | awk '{print $1}')

Create the API key resource with access to the provider-backed model alias:

curl -sS -X POST "http://127.0.0.1:3001/admin/v1/apikeys" \
  -H "Authorization: Bearer ${AISIX_ADMIN_KEY}" \
  -H "Content-Type: application/json" \
  --data-binary @- <<EOF
  {
    "key_hash": "${CALLER_KEY_HASH}",
    "allowed_models": ["fireworks-deepseek-prod"]
  }
EOF

The allowed_models value must match the model alias you created.

Verify the Provider Connection​

Send a chat-completions request through the AISIX proxy:

curl -sS -X POST "http://127.0.0.1:3000/v1/chat/completions" \
  -H "Authorization: Bearer ${AISIX_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "fireworks-deepseek-prod",
    "messages": [
      {
        "role": "user",
        "content": "Say hello from Fireworks AI."
      }
    ]
  }'

The response should be an OpenAI-compatible chat-completions response that echoes the caller-facing alias. If the provider exposes logs, metrics, request IDs, or usage records, use them to confirm that the request reached the intended upstream account and model.

If the gateway returns an upstream authentication error, check the provider key's secret. If it returns an upstream route error, check api_base and the provider model ID in model_name.

Support Provider-Specific Behavior​

The provider must accept OpenAI chat-completions requests. A provider with a different request format needs a native adapter protocol family. Other OpenAI-shaped routes work only when the provider implements the corresponding upstream endpoint; see Provider Compatibility for the route requirements.

AISIX preserves reasoning_content and normalizes reasoning to that canonical field. If a provider streams reasoning from a different delta path, use the response.reasoning_field override on the provider key.

Next Steps​

You have now connected AISIX to a public OpenAI-compatible provider. Continue with these guides:

  • Model Aliases: configure routing, health behavior, or cost metadata for the alias.
  • Provider Compatibility: review supported proxy endpoints and provider-specific boundaries.