MiniMax API access has two practical paths for teams that already use OpenAI-style clients. You can call MiniMax directly with the official MiniMax OpenAI SDK configuration, or you can evaluate MiniMax through a unified router workflow where one gateway base URL, one key, usage logs, pricing checks, and rollback rules stay in the same place as the rest of your model stack.
The direct MiniMax path uses the official MiniMax base URL, https://api.minimax.io/v1, and a MiniMax API key. The Flatkey path uses https://router.flatkey.ai/v1, a Flatkey key, and a MiniMax model row from the current Flatkey catalog. Before production traffic, confirm the current model ID, route availability, pricing unit, and usage-log behavior in Flatkey pricing or the dashboard.
This guide explains how to plan MiniMax API access through one OpenAI-compatible router. It covers what the official MiniMax docs confirm, what Flatkey changes operationally, how to test Python and JavaScript clients, and how to avoid turning a base URL change into an unreviewed production risk.
Quick Answer: MiniMax API Access Through A Unified Router
If your app already uses the OpenAI Python or JavaScript SDK, MiniMax API access can start as a configuration exercise instead of a full provider SDK rewrite.
| Decision | Direct MiniMax | MiniMax Through Flatkey |
|---|---|---|
| API key | MiniMax pay-as-you-go API key | Flatkey API key |
| Base URL | https://api.minimax.io/v1 |
https://router.flatkey.ai/v1 |
| Primary goal | Call MiniMax directly with MiniMax account billing | Evaluate MiniMax beside other models behind one router |
| Model choice | MiniMax model from official docs and account access | MiniMax row from current Flatkey pricing or dashboard |
| Validation | Response, feature support, direct MiniMax pricing | Response, route status, Flatkey usage log, pricing unit, quota, rollback |
Use direct MiniMax when you want only a MiniMax account integration. Use Flatkey when MiniMax needs to sit inside the same access, billing, quota, usage-log, and model-evaluation workflow as GPT, Claude, Gemini, DeepSeek, Qwen, Seedance, image models, and other providers.
What The Official MiniMax Docs Confirm
The official MiniMax API overview covers language, speech, video, image, music, file management, and MiniMax MCP surfaces. It also explains that pay-as-you-go users create API keys from the MiniMax platform, while subscription keys are separate from pay-as-you-go API keys.
The official OpenAI SDK page is the most relevant source for router planning. It shows MiniMax models being called with OpenAI SDK clients by setting the MiniMax API key and base_url or baseURL to:
https://api.minimax.io/v1The same docs also include MiniMax-specific caveats. Some OpenAI parameters may be ignored, n only supports value 1, deprecated function_call is not supported in that path, and image/video inputs are documented for MiniMax-M3 while audio input is not currently supported in the OpenAI-compatible message-content path.
That means MiniMax API access should be treated as feature-level compatibility, not blanket parity. Test basic chat first, then streaming, tool calls, image or video inputs, pricing behavior, errors, and any parameter your application depends on.
What MiniMax API Pricing Means For Router Planning
Search demand around MiniMax API access often includes pricing questions. The official MiniMax pay-as-you-go page separates text, audio, video, image, music, and MCP pricing. For text models, the page lists input, output, cached input, and cached output prices for rows such as MiniMax-Text-01, MiniMax-M2.7, and MiniMax-M2. For other modalities, the unit changes: audio is priced by characters or voice operations, video by model/resolution/duration rows, image by generated image, music by song, and MCP by request.
Do not copy direct MiniMax prices into a routed budget. Direct MiniMax pricing explains the provider-side unit. Flatkey routed usage needs the current Flatkey model row, group, endpoint type, route status, and actual usage log. Use the broader AI model pricing comparison workflow when you are comparing MiniMax against other text, audio, video, or image models.
Where Flatkey Changes The MiniMax Setup
Flatkey changes the operational surface around MiniMax API access. Instead of each app owning a separate MiniMax base URL, key, billing check, and model switch, the app can be evaluated against one router base URL:
https://router.flatkey.ai/v1Flatkey's public product copy positions the platform around one API key, multi-model access, clear pricing, unified billing, and one dashboard for keys, usage, and routing. MiniMax proof for this article comes from the live Flatkey pricing snapshot, not from an evergreen promise.
The June 16, 2026 Flatkey pricing snapshot returned 638 total model rows and 9 MiniMax-named rows. Those MiniMax rows exposed openai as a supported endpoint type and were in the Standard group. The same snapshot did not show clean availability: 7 rows were unknown_failure and 2 were official_unsupported. Treat that as dated catalog evidence only. Before real MiniMax API access through Flatkey, confirm the current route status in pricing or the dashboard and run a smoke test.
Base URL Migration Pattern
Keep MiniMax API access in configuration. The base URL, key, and model string should be easy to switch without editing application logic.
FLATKEY_API_KEY="sk-fk-your-key"
OPENAI_BASE_URL="https://router.flatkey.ai/v1"
FLATKEY_MINIMAX_MODEL="replace-with-current-flatkey-minimax-model-id"
# Optional direct MiniMax values for comparison or rollback.
MINIMAX_API_KEY="replace-with-minimax-api-key"
MINIMAX_BASE_URL="https://api.minimax.io/v1"The key distinction is ownership of the route. Direct MiniMax tests use a MiniMax key and MiniMax base URL. Flatkey tests use a Flatkey key and the Flatkey router base URL. Do not mix a MiniMax key with the Flatkey base URL, or a Flatkey key with the direct MiniMax base URL.
Python Template For MiniMax Through Flatkey
Template only: run this with a valid Flatkey key and a confirmed Flatkey MiniMax model ID before using it in production.
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["FLATKEY_API_KEY"],
base_url=os.environ.get("OPENAI_BASE_URL", "https://router.flatkey.ai/v1"),
)
response = client.chat.completions.create(
model=os.environ["FLATKEY_MINIMAX_MODEL"],
messages=[
{
"role": "user",
"content": "Reply with one sentence confirming the MiniMax route is configured.",
}
],
)
print(response.choices[0].message.content)
print(response.usage)The code shape is intentionally ordinary OpenAI SDK usage. The production work is choosing the right Flatkey MiniMax model ID, confirming the route is available, testing the features your app uses, and checking the request in Flatkey usage logs.
JavaScript Template For MiniMax Through Flatkey
Template only: run this with a valid Flatkey key and a confirmed model ID from the current Flatkey catalog.
import OpenAI from "openai";
const client = new OpenAI({
apiKey: process.env.FLATKEY_API_KEY,
baseURL: process.env.OPENAI_BASE_URL || "https://router.flatkey.ai/v1",
});
const response = await client.chat.completions.create({
model: process.env.FLATKEY_MINIMAX_MODEL,
messages: [
{
role: "user",
content: "Reply with one sentence confirming the MiniMax route is configured.",
},
],
});
console.log(response.choices[0].message.content);
console.log(response.usage);For teams already using OpenAI-compatible JavaScript clients, this keeps MiniMax API access small enough to review as a configuration change. The route still needs feature and availability checks before real users depend on it.
Direct MiniMax Versus Flatkey: What To Test
The useful gap in current search results is not another MiniMax model list. Official docs already cover the direct API. The missing piece is a router checklist for deciding whether direct MiniMax is enough or whether one base URL is cleaner for the way your product operates.
| Workflow Need | Direct MiniMax Check | Flatkey Router Check |
|---|---|---|
| Basic chat | Use https://api.minimax.io/v1, a MiniMax key, and an official model. |
Use https://router.flatkey.ai/v1, a Flatkey key, and a current Flatkey MiniMax model ID. |
| Streaming | Confirm streaming output and final usage behavior in the MiniMax SDK path. | Confirm stream chunks, timeout behavior, and usage logging through Flatkey. |
| Tool calls | Use tools; do not rely on deprecated function_call. |
Confirm the same tool schema passes through the selected Flatkey route. |
| Parameters | Respect MiniMax caveats such as n: 1 and ignored OpenAI parameters. |
Verify unsupported-parameter handling and app parser behavior through the router. |
| Multimodal input | Confirm which MiniMax model supports image or video inputs through OpenAI-compatible content parts. | Confirm the exact Flatkey model row and endpoint support the same payload shape. |
| Pricing review | Check MiniMax pay-as-you-go pricing for the direct provider unit. | Check Flatkey pricing, row status, group, and actual usage logs. |
| Multi-provider routing | Requires separate setup for non-MiniMax providers. | Evaluate MiniMax beside other models behind one key and dashboard. |
Smoke Test Runbook
A MiniMax API access smoke test should prove both API behavior and router visibility.
- Choose one MiniMax model row from current Flatkey pricing or the dashboard.
- Confirm the row status is acceptable for testing; do not rely on a stale catalog snapshot.
- Create or select a low-risk Flatkey key for testing.
- Set
OPENAI_BASE_URLtohttps://router.flatkey.ai/v1. - Run a simple non-streaming chat prompt.
- Confirm the response shape works with your app parser.
- Check Flatkey usage logs for model, status, token usage, and cost.
- Run a bad-model test and record the error shape.
- Run streaming, tools, image/video input, or other advanced features only if your app uses them.
- Set a small quota before real traffic is sent.
- Keep direct MiniMax or prior provider settings as rollback configuration until the route is stable.
The goal is not just to make a MiniMax response appear. The goal is to know where the request went, whether the selected route is healthy, what it cost, how failures look, and how quickly you can restore the previous route.
Common Mistakes
- Using a MiniMax API key with the Flatkey base URL, or a Flatkey key with the MiniMax base URL.
- Copying a MiniMax model name from official docs without confirming the Flatkey catalog string.
- Assuming OpenAI-compatible means every MiniMax parameter behaves exactly like OpenAI.
- Ignoring documented caveats such as unsupported deprecated
function_call, ignored parameters, ornlimits. - Testing only non-streaming chat when production uses streaming, tools, image input, or video input.
- Skipping the Flatkey row-status, usage-log, quota, and pricing checks after a successful response.
- Publishing code snippets with real-looking keys or untested production model IDs.
These are small details, but they are where MiniMax API access migrations can fail. A router makes access easier to operate; it does not remove the need to test the exact request shape.
How This Fits With Existing Flatkey Migration Guides
If this is your first router migration, start with the broader OpenAI-compatible API migration guide. It covers base URL configuration, smoke tests, rollback, and dashboard checks that apply to any provider route.
Then use this MiniMax-specific guide for the provider details: the MiniMax OpenAI SDK base URL, pay-as-you-go API keys, MiniMax model and pricing units, documented parameter caveats, route-status checks, and the Flatkey catalog proof. For a similar model-family workflow, compare the Qwen API router guide.
FAQ
How do I get MiniMax API access?
You can get MiniMax API access directly through the MiniMax platform with a pay-as-you-go API key, or evaluate MiniMax through Flatkey with a Flatkey key and https://router.flatkey.ai/v1. The direct path uses MiniMax account billing; the Flatkey path keeps the route inside a multi-model gateway workflow.
Is the MiniMax API OpenAI compatible?
MiniMax documents OpenAI SDK usage with https://api.minimax.io/v1 as the base URL. Compatibility is feature-level: test the exact endpoint, parameters, model, streaming behavior, tool schema, and multimodal input your app uses.
What is the direct MiniMax OpenAI-compatible base URL?
The official MiniMax OpenAI SDK guide uses https://api.minimax.io/v1 as the base URL for MiniMax models.
What base URL should I use for MiniMax through Flatkey?
Use https://router.flatkey.ai/v1 for MiniMax through Flatkey. Then choose a current MiniMax model row from Flatkey pricing or the dashboard and test the request before production traffic.
Can I use the same MiniMax model ID from official docs in Flatkey?
Not automatically. Model strings, aliases, endpoint support, and route status can differ by catalog and gateway. Pick the model ID from Flatkey on the day you test and keep it in configuration.
Does OpenAI-compatible mean full feature parity?
No. OpenAI-compatible usually means common request and response shapes work for supported endpoints. It does not guarantee identical behavior for every model, parameter, endpoint, streaming mode, tool call, or multimodal payload.
How should I budget MiniMax through a router?
Use MiniMax pricing docs for direct provider context and Flatkey pricing for routed usage. Then verify actual request cost in Flatkey logs because model rows, groups, endpoint types, cache behavior, and availability status can change.
View Pricing Before You Route Production Traffic
MiniMax API access through an OpenAI-compatible router is a practical evaluation path when your app already uses OpenAI-style SDK calls. Keep the change small: update the base URL, use a Flatkey key, select a current MiniMax model, run the smoke tests, and verify route status, usage, pricing, and rollback before rollout.
View Pricing to confirm current Flatkey MiniMax model rows, route status, and cost units before you send production traffic.
