Skip to main content
API7.ai Logo

MiniMax

MiniMax provides hosted generative models through its platform API. Applications call MiniMax through stable AISIX aliases while the gateway keeps the upstream credential out of client code.

Prerequisites​

Before starting, prepare the following:

  • One AISIX setup:
    • For AISIX Cloud, an environment with an attached gateway and a write-scoped admin token. For On-Premises, follow the AISIX Cloud Quickstart. To request Hybrid Cloud access, contact API7.
    • For the open-source AISIX gateway, prepare either a local AISIX installation or the Docker setup from the Open-Source AISIX Gateway Quickstart. Configure the gateway to load a declarative resources file.
  • A MiniMax API key from the MiniMax platform.
  • curl and jq.

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 with AISIX Cloud​

Export the AISIX Cloud connection details:

# AISIX_CP is the Admin API base URL; include /api and omit a trailing slash
# The local On-Premises quickstart uses http://localhost:8080/api
export AISIX_CP="YOUR_AISIX_CLOUD_ADMIN_API_URL"
export AISIX_TOKEN="YOUR_ADMIN_TOKEN"
export ENV_ID="YOUR_ENVIRONMENT_ID"

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

MiniMax is a community catalog provider. AISIX connects through the openai adapter and authenticates upstream requests with a bearer token. You must also set api_base explicitly because the catalog's published base URL is not the root required by the adapter. See Set the Correct Base URL.

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 AISIX 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 Keys.

❸ 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.

Configure with the Open-Source AISIX Gateway​

Export the upstream credential and choose the caller API key that applications will send to the gateway:

export MINIMAX_API_KEY="YOUR_PROVIDER_API_KEY"
export CALLER_API_KEY="YOUR_CALLER_API_KEY"

Create a complete declarative resources file for this provider:

resources.yaml
_format_version: "1"

provider_keys:
  - display_name: "minimax-prod"
    provider: "minimax"
    adapter: "openai"
    api_key: ${MINIMAX_API_KEY}
    api_base: "https://api.minimax.io/v1"

models:
  - display_name: "minimax-m3-prod"
    provider: "minimax"
    model_name: "MiniMax-M3"
    provider_key: "minimax-prod"

api_keys:
  - display_name: "minimax-caller"
    key_env: CALLER_API_KEY
    allowed_models:
      - "minimax-m3-prod"

If AISIX is installed locally, validate the file before loading it:

aisix validate --resources resources.yaml

After validation, start the gateway with the referenced environment variables in its process environment. Reload an existing gateway only if those variables are already available to the process; otherwise, restart it with the updated environment.

If you use Docker, adapt the validation and startup commands in the Open-Source AISIX Gateway Quickstart. Mount this resources.yaml file and pass every environment variable it references with -e in both commands. After the resources load, prepare the shared verification request below:

export AISIX_API_KEY="$CALLER_API_KEY"

Verify the Provider Connection​

Export the AISIX gateway origin:

# The local quickstarts use http://127.0.0.1:3000
export AISIX_PROXY="YOUR_AISIX_GATEWAY_ORIGIN"

Send a chat-completions request through the AISIX proxy:

curl -sS -X POST "$AISIX_PROXY/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. It does not preserve MiniMax's separate reasoning_details array. 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 minimax has no AISIX-curated adapter mapping, the provider key is the only place to record a MiniMax-specific wire difference. AISIX sends top-level request fields unchanged unless you configure request.param_renames. MiniMax-M3 currently accepts both max_tokens and max_completion_tokens, so no rename is required for the model in this guide. Add one only when the selected model requires a different field name.

MiniMax-M3 defaults reasoning_split to false, which keeps thinking inside <think> tags in content; AISIX preserves that content. If you set reasoning_split to true, MiniMax also emits reasoning_content and a reasoning_details array. On /v1/chat/completions, AISIX preserves reasoning_content but drops reasoning_details; the Responses bridge does not expose either field. The response.reasoning_field override cannot retain the array. MiniMax requires the complete array in conversation history for interleaved thinking with tools, so leave split reasoning disabled for multi-turn tool loops through the normalized chat or Responses endpoints. If your application depends on the complete Anthropic thinking and tool-use contract from MiniMax, use the Anthropic-compatible surface.

For a different model that streams scalar reasoning from a nonstandard delta path, set response.reasoning_field on the provider key to that path. AISIX then maps it to delta.reasoning_content for callers. Confirm any override with a streaming request against the configured model.

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.

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​

This alias uses the OpenAI-compatible text and multimodal chat surface from MiniMax. MiniMax also provides native image, video, speech, music, and file APIs, but their paths and bodies do not match the normalized media and job contracts in AISIX.

RouteBehavior with a MiniMax alias
/v1/chat/completionsSupported, including stream: true. MiniMax-M3 accepts image and video inputs here for multimodal understanding; this route does not generate images or videos.
/v1/responsesSupported through the Responses bridge. AISIX translates the request to chat completions; it does not call a MiniMax /v1/responses endpoint. OpenAI-specific Responses fields without a chat equivalent are ignored.
/v1/messagesSupported for Anthropic-shaped callers through translation. The catalog alias is OpenAI-backed, so /v1/messages/count_tokens returns a 400 error for it. The separate BYO Anthropic alias supports the MiniMax Messages surface and token counting.
/v1/embeddingsDo not assume support. AISIX forwards an OpenAI-shaped embeddings body to {api_base}/embeddings without translation, but MiniMax's current public API documentation does not define an OpenAI-compatible embeddings contract or embedding model. See Embeddings.
/v1/images/generationsRejected with a 400 error. MiniMax image generation uses the native /v1/image_generation contract, which you can access through a passthrough route.
/v1/rerankRejected with a 400 error. The route accepts only the openai, cohere, and jina provider values.
/v1/videosReturns 501 Not Implemented. MiniMax video generation uses the native /v1/video_generation contract, which you can access through a passthrough route.
/passthrough/minimax/*Available through a configured passthrough route for native routes such as /image_generation, /video_generation, /t2a_v2, and /files/retrieve. AISIX forwards the native body and response without translating them.

The /passthrough/minimax paths on this page assume a passthrough route claiming that prefix, with MiniMax's API root as its target_url and this provider key attached; grant the route name on the caller key's allowed_routes. A route relays to one fixed target, so if you configure more than one MiniMax account or base URL, create a separate route per account. AISIX does not rewrite a model value in the native body. It detects chat, completions, and Responses envelopes and records supported usage fields. Requests without a recognized carrier field remain opaque: buffered responses record zero tokens, while opaque SSE can still record top-level supported usage fields.

With a route targeting the base in this guide, passthrough 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/image_generation and /passthrough/minimax/image_generation therefore reach https://api.minimax.io/v1/image_generation 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: