Skip to main content
API7.ai Logo

MiniMax

Connect AISIX AI Gateway to MiniMax so applications can call MiniMax-hosted models through the gateway's OpenAI-compatible API. AISIX keeps the MiniMax credential on the gateway side. It authorizes model access with caller API keys and allowlists, and applies the same rate-limit and usage-accounting controls as other model aliases.

MiniMax reaches AISIX through the community catalog path: minimax is a provider ID in the models.dev catalog, but it is not one of the AISIX-curated featured entries. The catalog default assigns the openai adapter with HTTP bearer authentication, and it leaves the upstream root to you. On this provider that last part matters more than usual, because the base URL the catalog publishes is not the one the openai adapter needs. Read Set the Correct Base URL before you create the provider key.

Prerequisites​

The following examples configure the upstream through the AISIX Cloud Admin API. Before configuring the upstream, prepare the following:

Export the connection details used by every request below:

# Replace with your values
export AISIX_CP="http://localhost:8080/api"
export AISIX_TOKEN="aisix_pat_YOUR_ADMIN_TOKEN"
export ENV_ID="YOUR_ENVIRONMENT_ID"

Set the Correct Base URL​

MiniMax publishes two upstream surfaces for the same models:

SurfaceRootRequest format
OpenAI SDKhttps://api.minimax.io/v1OpenAI chat completions
Anthropic SDKhttps://api.minimax.io/anthropicAnthropic Messages

The community catalog entry for minimax publishes https://api.minimax.io/anthropic/v1, the Anthropic-compatible surface written out with the version segment that the Anthropic SDK would otherwise append, while the catalog default assigns the openai adapter. Those two do not fit together. If you omit api_base, AISIX accepts the provider key, fills in that catalog value, and then sends OpenAI-shaped chat-completions requests to an endpoint that expects Anthropic-shaped Messages requests, and every call through the alias fails at the upstream.

caution

Always set api_base to https://api.minimax.io/v1 on a minimax provider key. The gateway appends the endpoint path, such as /chat/completions, to whatever root you configure, so the root must be the one that MiniMax's OpenAI-compatible /chat/completions hangs off.

To use the Anthropic-compatible surface instead, see Use the Anthropic-Compatible Surface.

Configure the MiniMax Upstream​

Create a provider key, model alias, and caller API key for the MiniMax-backed chat-completions route.

Create a Provider Key​

Create the provider key that stores the MiniMax credential and API root:

# Replace with your value
export MINIMAX_API_KEY="YOUR_PROVIDER_API_KEY"

PROVIDER_KEY_ID=$(curl -sS -X POST "$AISIX_CP/provider_keys" \
  -H "Authorization: Bearer $AISIX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "display_name": "minimax-prod",
    "provider": "minimax",
    "api_key": "'"${MINIMAX_API_KEY}"'",
    "api_base": "https://api.minimax.io/v1",
    "allowed_environments": ["'"${ENV_ID}"'"]
  }' | jq -r '.provider_key.id')

echo "$PROVIDER_KEY_ID"

❶ provider is minimax. The Cloud Admin API accepts the value because minimax is a models.dev catalog entry, and it derives the adapter from the catalog; the adapter field is only accepted on BYO provider keys.

❷ api_key stores the MiniMax API key. MiniMax authenticates its OpenAI-compatible surface with HTTP bearer authentication, which is what the openai adapter already sends. The value follows the credential-handling behavior in Provider Credentials.

❸ api_base is https://api.minimax.io/v1, the base_url that MiniMax documents for OpenAI client libraries. It is the single most important field on this page. Omitting it does not fail the create call, because the catalog publishes a default; it fails every later chat request, because that default points at the Anthropic-compatible root.

The command captures the returned provider key ID in PROVIDER_KEY_ID.

Create a Model​

MiniMax model IDs are case-sensitive and carry no vendor prefix. They follow the pattern MiniMax-<generation>, with a capital M on both halves of the vendor name, a decimal generation number, and an optional -highspeed suffix on the low-latency variant of a generation. Do not lowercase them, and do not add a minimax/ prefix carried over from an aggregator.

Current model IDs include the following:

Model IDNotes
MiniMax-M3Latest generation. Accepts text, image, and video input on the OpenAI-compatible chat-completions route.
MiniMax-M2.7Previous flagship generation, text input only.
MiniMax-M2.7-highspeedLow-latency variant of the same generation.

The MiniMax-M2.5, MiniMax-M2.5-highspeed, MiniMax-M2.1, and MiniMax-M2 IDs remain in the catalog as earlier generations. Check the MiniMax model documentation for the current list before you create an alias.

Create the model alias callers will send in requests:

MODEL_ID=$(curl -sS -X POST "$AISIX_CP/environments/$ENV_ID/models" \
  -H "Authorization: Bearer $AISIX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "display_name": "minimax-m3-prod",
    "model_name": "MiniMax-M3",
    "provider_key_id": "'"${PROVIDER_KEY_ID}"'"
  }' | jq -r '.model.id')

echo "$MODEL_ID"

❶ display_name is the alias callers send in model.

❷ model_name is the MiniMax model ID, spelled exactly as MiniMax publishes it, for example MiniMax-M3.

❸ provider_key_id attaches the alias to the MiniMax provider key.

To configure cost metadata for budget accounting or usage reports, see Model Aliases.

Create a Caller API Key​

Create the caller API key that can access the model alias. The plaintext key is server-generated and returned once in the create response, so capture it now:

AISIX_API_KEY=$(curl -sS -X POST "$AISIX_CP/environments/$ENV_ID/api_keys" \
  -H "Authorization: Bearer $AISIX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "display_name": "minimax-caller",
    "allowed_models": ["'"${MODEL_ID}"'"]
  }' | jq -r '.plaintext')

echo "$AISIX_API_KEY"

The allowed_models value must reference the model ID captured in the previous step. After the write, the configuration projects to attached gateways automatically.

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": "minimax-m3-prod",
    "messages": [
      {
        "role": "user",
        "content": "Say hello from MiniMax."
      }
    ]
  }'

The gateway returns an OpenAI-compatible response that echoes the caller-facing alias minimax-m3-prod.

If the request fails, check these in order:

  1. api_base on the provider key. An upstream 404, or an upstream error that mentions an unexpected request field, usually means the key is still pointing at https://api.minimax.io/anthropic/v1 rather than https://api.minimax.io/v1.
  2. api_key on the provider key, if the upstream returns an authentication error.
  3. The spelling and capitalization of model_name. MiniMax model IDs are case-sensitive.

Understand the Community Catalog Path​

A featured provider carries an AISIX-curated adapter, authentication scheme, default base URL, and any request or response rewrites the upstream needs. minimax has none of those. The dashboard groups it under the community catalog, and AISIX makes exactly three decisions on its behalf:

  • The adapter is openai.
  • The authentication scheme is HTTP bearer.
  • The default base URL is whatever models.dev publishes for the provider, cached in AISIX provider metadata.

Everything else is yours to supply. In practice this means:

  • The base URL is your responsibility. On this provider the published default is wrong for the assigned adapter, so set it explicitly, as described in Set the Correct Base URL. AISIX rejects a create call with a 400 error only when models.dev publishes no base URL at all for a provider; minimax publishes one, so the request succeeds and the mismatch surfaces later.
  • No request or response rewrites are registered. AISIX forwards the caller's chat-completions body to MiniMax with no parameter renames, and normalizes reasoning from the canonical delta.reasoning_content path only. If MiniMax renames a parameter or streams reasoning somewhere else, you configure that yourself. See Configure Request and Response Overrides.
  • The upstream contract is not tracked for you. When MiniMax changes its wire shape, no catalog entry changes with it. Verify a representative request against a non-production alias after a MiniMax API update.

Usage records still tag the provider key as a catalog key branded minimax, and mark it as not featured, so community-catalog traffic stays distinguishable in usage data.

None of this makes minimax a lesser upstream. It is a supported catalog provider with the same caller keys, allowlists, rate limits, budgets, and usage accounting as any other alias. The difference is where the responsibility for the wire contract sits.

Configure Request and Response Overrides​

Because there is no curated catalog entry for minimax, the provider key is the only place to record a MiniMax-specific wire difference. Two overrides cover the common cases.

To rename a top-level request parameter, set request.param_renames. The following example delivers a caller's max_tokens under the current OpenAI name:

{
  "request": {
    "param_renames": {
      "max_tokens": "max_completion_tokens"
    }
  }
}

AISIX registers no rename for minimax, so without this block both names pass through exactly as the caller sent them. Add a rename only after you confirm which name your MiniMax model accepts.

The second override, response.reasoning_field, normalizes reasoning that a model streams from a nonstandard path. MiniMax reasoning models stream thinking content in choices[0].delta.reasoning_content, the same canonical field AISIX preserves, so the default streaming shape needs no override. Confirm this with a streaming request against the model you configured. If a MiniMax option moves reasoning to a different delta path, set response.reasoning_field on the provider key to that path and AISIX maps it back to delta.reasoning_content for callers.

Overrides apply to every model that references the provider key, so test them against a non-production alias first. See Provider-Specific Overrides.

Connect the China Platform​

MiniMax operates a separate platform for mainland China, with its own developer console and hostname. It appears in the catalog as a distinct provider ID, minimax-cn, and each platform issues its own API keys, so the China platform needs its own provider key.

The same base-URL correction applies: the catalog default points at the Anthropic-compatible root, and the OpenAI-compatible root is https://api.minimaxi.com/v1. Note the extra i in the hostname.

{
  "display_name": "minimax-cn-prod",
  "provider": "minimax-cn",
  "api_key": "YOUR_MINIMAX_CN_API_KEY",
  "api_base": "https://api.minimaxi.com/v1",
  "allowed_environments": ["YOUR_ENVIRONMENT_ID"]
}

The catalog lists the same model IDs for both platforms. Availability of a given generation is not guaranteed to match, so verify against the China platform documentation rather than assuming parity.

Use the Anthropic-Compatible Surface​

Anthropic-shaped clients do not need the MiniMax Anthropic endpoint. AISIX already accepts Anthropic Messages requests at /v1/messages and translates them onto the OpenAI-compatible alias you configured above. See Anthropic Messages API.

Route to MiniMax's own Anthropic surface only when you need the upstream to receive the Anthropic wire shape unmodified. The anthropic adapter is not available on a catalog provider key, because AISIX derives the adapter from the catalog, so use a bring-your-own-endpoint key instead:

{
  "display_name": "minimax-anthropic-prod",
  "provider": "byo",
  "adapter": "anthropic",
  "api_key": "YOUR_MINIMAX_API_KEY",
  "api_base": "https://api.minimax.io/anthropic",
  "allowed_environments": ["YOUR_ENVIRONMENT_ID"]
}

The anthropic adapter appends /v1/messages to the configured root, so https://api.minimax.io/anthropic is the correct value here. A BYO key requires a non-empty api_key and api_base; its adapter is immutable after creation.

note

A BYO provider key is attributed as a bring-your-own upstream in usage records and carries no branded provider value, so its usage does not aggregate with the minimax catalog key's usage under one provider.

Endpoint Coverage​

MiniMax is an inference-only upstream, so only part of the proxy surface applies to a MiniMax-backed alias.

RouteBehavior with a MiniMax alias
/v1/chat/completionsSupported, including stream: true.
/v1/responsesSupported through the Responses bridge over the chat adapter path.
/v1/messagesSupported for Anthropic-shaped callers through translation. Token counting at /v1/messages/count_tokens requires an Anthropic-backed model and returns a 400 error otherwise.
/v1/embeddingsVerify before use. AISIX forwards an OpenAI-shaped embeddings body to {api_base}/embeddings without translation, and the OpenAI-compatible surface MiniMax documents covers chat completions. See Embeddings.
/v1/images/generationsRejected with a 400 error. The route accepts only models whose provider is openai.
/v1/rerankRejected with a 400 error. The route accepts only the openai, cohere, and jina provider values.
/v1/videosReturns 501 Not Implemented. The route dispatches by provider and does not map minimax.
/passthrough/minimax/*Supported for provider-native routes, with limited gateway normalization. See Provider Passthrough.

Passthrough borrows the api_base from the provider key, so requests resolve against https://api.minimax.io/v1. That root already ends in a version segment, and the gateway strips one redundant leading version segment from the passthrough path when it matches. Both /passthrough/minimax/v1/<path> and /passthrough/minimax/<path> therefore reach https://api.minimax.io/v1/<path> rather than a doubled /v1/v1/ URL.

Next Steps​

You have now connected AISIX to MiniMax and verified the model alias. Continue with these guides: