Many developers search for "Moonshot API key," open platform.moonshot.cn, and find themselves redirected to a different domain, which makes them wonder whether they have landed on the wrong site. The platform has in fact been rebranded: Moonshot is the company and open-platform brand, Kimi is the model brand, and API requests still use the moonshot domain. This article follows the actual 2026 entry points and explains account levels, key permissions, storage, rotation, and 401 troubleshooting.

Note: Moonshot and Kimi are trademarks of their respective owners. This article is a technical integration guide only. Platform entry points, verification requirements, and key management rules may change, so refer to the current console pages.

1. Where the Moonshot Open Platform Lives Now

platform.moonshot.cn currently redirects to platform.kimi.com, and the international site platform.moonshot.ai redirects to platform.kimi.ai. The console, account, balance, and keys are all managed inside the Kimi API open platform.

The API request domains, however, have not changed: the China site is still api.moonshot.cn, and the international site is still api.moonshot.ai. Some older tutorials replaced only the console screenshots without explaining this, which made the platform look as if it had disappeared.

Remember the three layers: Moonshot is the platform brand, Kimi is the model brand, and api.moonshot.* is the API domain. They are not three separate accounts. China-site and international-site accounts, balances, and keys are isolated from each other, and a key must match its site.

2. Choose the Account Type First: Unverified, Personal, or Enterprise

Verification status Max projects Max API keys Suitable for
Unverified 1 10 Short-term trials
Personal verification 20 50 Individual developers, small teams
Enterprise verification 50 100 Multiple projects and members

These figures come from the current documentation and may be adjusted in the console. After enterprise verification, an organization can invite members, assign permissions per project, and issue invoices; personal verification cannot invite members. The rules for changing the verified entity follow the console, so decide before registration whether to use a personal or enterprise entity. Changing the entity later often involves contracts and invoices.

The organization level also offers an IP allowlist, available to both personal and enterprise verified organizations. It applies to the whole organization and restricts every key under it at once, with a maximum of 20 public IPv4 addresses or CIDRs. IPv6 and private addresses are not accepted. Each save overwrites the entire list, so do not enable it casually when your egress IP is not fixed.

3. The Right Order for Creating a Key

  1. Sign in at platform.kimi.com and open the console.
  2. Create a project first, named by business line or environment, for example crm-prod or crm-test.
  3. Open the API Keys page and create a key whose name includes the project, environment, and purpose.
  4. Copy the key; if the page shows it only once, store it in a secret manager immediately.
  5. Verify the key and the site with GET /v1/models or a minimal request.
  6. Record the owner, project, creation time, and planned rotation date.

A key belongs to a project, and usage is also recorded against the project; all projects share the organization balance and organization-level rate limits. Project administrators can set monthly or daily budgets, TPM caps, and SMS alerts. Budget enforcement has a delay of about ten minutes, so do not treat it as a real-time gate.

Each member should create their own key. When a member is removed from a project, the keys they created stop working, which makes accountability much easier than sharing one key among several people.

4. What a Key Can and Cannot Do

An API key is not an account password and does not carry "universal permissions." It can call the endpoints and models that the organization has assigned to its project, subject to the project budget, organization rate limits, and IP allowlist. If the console does not offer a way to scope a key to specific models or endpoints, do not assume that capability exists; when you need isolation, use separate projects, separate keys, and application-level quotas.

Also distinguish between products: a Kimi Code key is not interchangeable with an open-platform key. Using a Code product key against open-platform endpoints commonly returns 401 or 404. Member roles, top-up, and invoice permissions are also separate, so assign least privilege and do not treat "can create keys" as "can manage billing."

5. Environment Variables and Where Keys Live in Code

# .env stays local; never commit it
MOONSHOT_API_KEY=your-key

# .gitignore should include at least
.env
.env.*

In production, use the platform's secret management or inject environment variables. Keys must never appear in front-end code, mobile apps, or browser extensions; route all requests through a server. Filter the Authorization header out of logs, exception reports, and APM, recording only the key name or prefix. CI/CD should use a separate secret and never echo it into build logs. When several people share a development machine, one development key per person makes problems much easier to trace.

6. Diagnosing 401, 403, and 429

For a 401, check three things first: which site the key belongs to, whether the Base URL matches, and whether the key was deleted or has already been rotated. Then check that the copy is complete, that the header is Authorization: Bearer, and that the environment variable is actually loaded. Retest with a newly created key to separate a key problem from a configuration problem.

A 403 usually means the IP allowlist does not include the current egress IP, or the project lacks permission. The egress IP of NAT, proxies, and cloud functions may differ from what you expect.

For a 429, distinguish the error type: engine_overloaded_error means the server is busy, so wait for Retry-After and reduce concurrency; rate_limit_reached_error means the organization's RPM, TPM, TPD, or concurrency limit was exceeded; exceeded_current_quota_error usually means insufficient balance or arrears. The OpenAI SDK retries twice by default, so one failed call can turn into three requests; accounts with low quotas should keep this in mind.

7. Rotation, Revocation, and Leak Response

  • Rotate routine projects every 90 days, and core services more often.
  • On personnel changes, revoke first and reissue second; do not just edit a string in the code.
  • Revoke immediately after a leak, then review usage and billing; do not wait and observe.
  • Use overlapping rollout: deploy and verify the new key before revoking the old one.
  • Clean up keys that have gone unused for a long time to avoid hitting the count limit.
  • Keep only key names in logs, never full values.

8. Official Keys vs. Gateway Keys

An official platform key belongs to an account on the Kimi API open platform. Settlement, invoicing, and model scope follow that platform's rules, and it suits teams that use only Kimi and need a direct connection to the official endpoints.

A gateway key is created in the ZSQH AI Gateway. One key can call multiple models, and billing is settled uniformly in RMB, which suits teams that switch between models or want centralized key management. Available models and billing methods follow the model pricing page.

The two paths do not conflict: you can test through a gateway first and then decide which path production should take. Do not mix the two kinds of keys, because their Base URLs, authentication systems, and balance accounts are all different.

FAQ

Is a Moonshot API key the same as a Kimi API key?

They are credentials for the same open platform, just under different names. The platform is now called the Kimi API open platform, while the API domain still uses moonshot.

Why does platform.moonshot.cn redirect?

After the platform rebrand, the China site redirects to platform.kimi.com and the international site to platform.kimi.ai. The API domains api.moonshot.cn and api.moonshot.ai are unaffected.

Can I view the full key value after creating it?

Most platforms show it only once at creation and afterwards display only the name or prefix. If you did not save it, create a new key instead of trying to recover the old value.

Can one key serve several projects?

Technically it often can, but it is not advisable. Binding a key to a project makes billing and rate-limit attribution easier; sharing one across projects makes budgets and troubleshooting hard to control.

What should I do if calls fail after enabling the IP allowlist?

First confirm that the current egress IP is in the list, then check the actual egress of NAT, proxies, or cloud functions. Editing the allowlist overwrites the whole list, so write all addresses before saving.

Next Steps

Start by creating a test key in the ZSQH AI Gateway, get a minimal request working, and then split production keys by project. Available models and billing methods follow the model pricing page.

Related reading: