A MiniMax API key commonly comes from two sources: the MiniMax open platform, or a compatible entry point such as the ZSQH AI Gateway. Both can call models, but registration, key scope, and billing are separate. This article follows the actual order of operations — registration, creation, storage, permission isolation, rotation, and 401 troubleshooting — and closes with advice on choosing between an official key and a gateway key.
For teams integrating for the first time, remember one sentence: a key should not be as universal as possible; it should be split by environment, by person, and by purpose, and it should be stoppable, traceable, and replaceable. That way, if one key has a problem, not all of your business is affected.
Note: MiniMax is a trademark of its owner; this article is for technical explanation only. Platform entry points, key management, and quotas are subject to MiniMax's official documentation and console; models and billing are subject to the model pricing page on this site.
1. First, distinguish the three kinds of keys
MiniMax currently offers two common official key types: pay-as-you-go interface keys and subscription keys tied to the M Plan subscription. The former are created on the account's "Interface Keys" page and support language, video, voice, and image models; the latter are viewed on the subscription and billing page and are used for the M Plan subscription and purchased Credits. The third type is a ZSQH AI Gateway key, which is valid only inside the gateway and is used to call multiple enabled models through one entry point.
Do not mix the three. The most common incident is putting an official key into a gateway address, or sending a gateway key to the official endpoint, then repeatedly checking the code only to find that the address and key simply did not match.
| Key type | Where to create or view | Scope | Best for |
|---|---|---|---|
| Official pay-as-you-go key | Open platform "Interface Keys" | Models and endpoints enabled under the official account | MiniMax only, direct official billing |
| Official M Plan subscription key | Subscription and billing page | M Plan subscription and purchased Credits | Teams that already bought a subscription |
| Gateway key | ZSQH console | Models enabled inside the gateway | One entry point and one bill for multiple models |
2. Registration: confirm whether you are on the China site or the international site
MiniMax has two entry points: platform.minimax.cn and platform.minimax.io. Entry points, consoles, and Base URLs differ, so before registering, confirm which one your team can access and which one fits your billing. Do not register on the China site and then configure the key against the international address.
For team use, we recommend a "main account + sub-accounts" setup. China-site documentation states that the main account can create sub-accounts; sub-accounts share the main account's entitlements, rate limits, and API consumption and billing, but cannot view or manage payments. This gives every person their own login identity — when someone leaves, disable the sub-account instead of passing the main password around.
If the console asks for company information or verification, follow the on-page instructions; the flow you see at registration is authoritative.
3. Steps to create a key
- Log in to the MiniMax open platform and open the "Interface Keys" page in the user center. On the China site the path is
platform.minimax.cn/user-center/basic-information/interface-key. - Click create key and give it a clear purpose name, such as
prod-customer-serviceortest-zhang. - Select or confirm the permitted scope as prompted. If the page offers no model-level permission option, account-level permission is the current boundary.
- Copy the key immediately after creation and store it in a password manager or secrets manager. Do not screenshot it into a group chat, and do not put it in code comments.
- If you use M Plan, the subscription key is not on the interface keys page; view it on the subscription and billing page.
- Verify the key with one minimal request, confirming that the region, Base URL, and model name all match.
- Record the key's owner, purpose, creation date, and deactivation condition in the team ledger.
A note on step 3: public documentation does not describe a general "per-model key permission" mechanism; what the console shows is what applies. If you need to isolate business lines, prefer sub-accounts or separate keys per environment rather than expecting one key to manage everything.
4. Permission isolation: one key per environment
Split at least three ways: development, staging, and production. A production key lives only in server-side environment variables or a secrets manager; it is never shipped to browsers, mobile apps, or desktop clients. Test keys can carry a lower quota so they are easy to disable at any time.
If the team runs several business lines, split keys by business too: one for customer service, one for content generation, one for batch jobs. If one line misbehaves, you can disable just that key without affecting the rest, and usage is easier to attribute.
The goal of permission isolation is not extra paperwork but failure boundaries. One key serving everything saves effort in the short term and makes diagnosis hard in the long term.
5. Put the key in environment variables
Do not hardcode the key in code. The minimal example below is for local use; in production, use the platform's secrets manager or container secrets.
# .env (do not commit to Git)
MINIMAX_API_KEY=your-key
# Official China-site example; when using the gateway, replace with the gateway URL and in-site model name
MINIMAX_BASE_URL=https://api.minimax.cn/v1
MINIMAX_MODEL=MiniMax-M3.1-Flash
# .gitignore
.env
.env.*
Read the key in Python with os.environ["MINIMAX_API_KEY"]; do not make the key a default argument value. Three points: first, .env must be in .gitignore; second, do not bake keys into image layers in containers or CI; third, redact request headers before logging so Authorization never lands in logs.
If you use a secrets manager, give the application read-only access and log each retrieval. Do not paste keys into chat tools or document bodies.
6. Rotation and leak handling
Official documentation does not prescribe a fixed rotation period, so set your own based on risk: rotate core production keys every 90 days, and immediately on staff changes, device loss, or suspected leaks.
Rotate in the order "create new, switch, then disable old":
- Create a new key with a date in the name, such as
prod-2026-10. - Write the new key into the secrets manager and verify it in staging first.
- Shift production traffic gradually and watch error rate and usage.
- Once stable, disable the old key and keep a record of the operation.
- Check whether the old key had anomalous calls before it was disabled.
If you suspect a leak, do not just change a string in code. Disable or delete the key in the console immediately, create a new key, check billing and call logs, and contact platform support if needed. Official documentation also notes that publicly leaked keys may be disabled automatically by the platform, but automatic disabling is not a fallback you should rely on.
7. 401 troubleshooting: check the address first, then the key
A 401 means authentication failed; it does not mean low balance or rate limiting. Troubleshoot in this order:
- Is the header
Authorization: Bearer <key>, with a space between Bearer and the key? - Was the key copied completely, without leading or trailing spaces, newlines, or quotes?
- Is a China-site key paired with the China-site address, and an international key with the international address?
- Was an official key accidentally used against the gateway address, or a gateway key against the official address?
- Has the key been deleted, disabled, or does it belong to an expired subscription?
- Did the environment variable actually load? In containers, print the variable name, never the value.
A 403 usually indicates a permission or quota issue; 429 is rate limiting; a message such as insufficient balance points to balance. Treat 401 separately from those errors.
8. Official key vs. gateway key
If you use only MiniMax, can complete official registration and billing directly, and can manage each vendor's keys separately, direct official access is simpler. If you need MiniMax, Claude, GPT, DeepSeek, and other models together, or want one key, one bill, and one usage view, a gateway saves effort.
The cost of a gateway is one more dependency, so confirm three things: which MiniMax models are supported, whether billing rules are clear, and which support channel exists when something breaks. Test with a small amount first, then move production traffic. Check models and billing on model pricing, and create a test key from the sign-up page.
FAQ
Where is a MiniMax API key created?
Official pay-as-you-go keys are created on the "Interface Keys" page in the open platform's user center; M Plan subscription keys are viewed on the subscription and billing page. The exact path depends on the console of the site you registered on.
Can one key call text, voice, and video at the same time?
Official pay-as-you-go interface keys support language, video, voice, image, and other model families, but availability depends on account entitlements, model enablement, and endpoint type. Voice and video are mostly asynchronous task endpoints and cannot be used exactly like a chat endpoint.
Can the key live in a frontend app or mini program?
No. Frontend code, browser requests, and mini-program bundles can all be decompiled or captured. A key belongs on the server, with the server proxying requests; if direct access is unavoidable, use short-lived tokens or restricted permissions and accept the risk that the key may leak.
Does rotating a key require downtime?
No. Create the new key, verify it in staging, shift production traffic gradually, and disable the old key last. The key is a period when old and new keys coexist so that the switch does not fail all at once.
Can official and gateway keys be mixed?
No. Each key is valid only on its own platform and address. Mixing them typically shows up as 401 or 404; check first whether the Base URL and the key come from the same platform.
Next steps
First decide whether you need only MiniMax or a unified entry point for multiple models. For one model, follow official documentation to create a key. For a unified entry point, sign up for the ZSQH AI Gateway, create a test key, and check models and billing on the model pricing page. Either way, keep keys in environment variables and separate test from production.
Related reading:
