How to Get a Kimi API Key: Create, Store and Rotate It

A Kimi API key is a server credential, not a login shortcut. Create it in the official Kimi Open Platform console, store it as a secret, give each environment or team member an appropriate key, and revoke it immediately if exposure is possible.

Console labels, project controls, endpoints, and security features can change. Use the official developer documentation and the controls displayed in your own project as the operational source of truth.

This page owns the credential lifecycle: choose the right credential, create it, store it, verify authentication, rotate it, and revoke it. To send a first chat request, continue to the Kimi API Quickstart.

Open the Official API Keys Console

First, Choose the Right Credential

Several Kimi-related access routes can look similar but are not interchangeable. Creating the wrong key leads to failed authentication, unexpected billing, or a tool that cannot use the credential.

Credential or account	Created at	Use it for
Kimi Open Platform API key	`platform.kimi.ai`	Server applications, scripts, agents, automation, and direct requests to the Kimi API
Kimi Code credential	The official Kimi Code route shown by the product	Supported coding tools and Kimi Code workflows
Kimi consumer account	Kimi web or mobile app	Using Chat and membership features as an end user; it is not a general developer key
Third-party provider key	The selected provider	Calling that provider’s deployment and accepting its billing, model list, limits, and privacy terms

This guide covers the international Kimi Open Platform route, whose official API base URL is https://api.moonshot.ai/v1. A key issued by another regional or third-party platform must be used with that platform’s documented endpoint.

The API Key Lifecycle

Plan: decide who owns the account, project, charges, and recovery process.
Create: issue a key for one person, service, or environment—not for the entire company.
Store: place the complete value in an environment variable or secret manager before closing the creation dialog.
Assign: provide the minimum systems and people that need the secret.
Monitor: review usage, spend, failed authentication, and unexpected sources.
Rotate: replace the key on a schedule and whenever ownership or exposure changes.
Revoke: disable the old or compromised key after the replacement is working.

Create a Kimi API Key in the Official Console

Open the official API Keys console and sign in to the developer account that should own the usage charges.
Select the intended organization and project. A small test can use the default project, but production systems should have an intentional project boundary.
Choose the option to create a new API key.
Use a purpose-based label when the interface allows it, such as staging-wordpress-backend or developer-alex-local. Do not put a password, customer name, or confidential project detail in the label.
Create the key and copy the complete value immediately.
Store it in an approved password manager, secret manager, or deployment secret before closing the dialog.
Record the owner, project, environment, creation date, and planned rotation date without recording the key itself in the inventory.

Official Kimi API documentation explaining how to create and store an API key — **Official Kimi API instructions for creating an API key. No personal API key is displayed. Screenshot captured September 8, 2026.**

Store the Key Before You Test It

Kimi’s official API documentation warns against exposing keys in client-side code, public repositories, or logs and recommends environment variables. The examples below set the variable for a local session; production deployments should use the host’s encrypted secret system.

macOS or Linux

export MOONSHOT_API_KEY="paste-the-key-here"

For a persistent setup, use your shell’s secure configuration process or a secret manager. Do not commit the value to a dotfile repository.

Windows PowerShell

$env:MOONSHOT_API_KEY="paste-the-key-here"

This sets the variable for the current PowerShell session. Use Windows or your deployment platform’s secret-management feature for persistent production storage.

Local .env file

MOONSHOT_API_KEY=paste-the-key-here

Add the file to .gitignore before the first commit:

.env
.env.*
!.env.example

An example file may contain MOONSHOT_API_KEY= with an empty value, but never a real secret.

Verify Authentication Without Sending a Full Model Request

Use the official List Models endpoint as a narrow credential check. A successful response confirms that the server accepted the Bearer token and returns the models currently visible to the account. It does not test prompt quality or complete the application quickstart.

curl --request GET \
  --url https://api.moonshot.ai/v1/models \
  --header "Authorization: Bearer $MOONSHOT_API_KEY"

Expected interpretation:

A model list is returned: authentication worked and the account can see its current inventory.
HTTP 401: check the copied value, environment variable, endpoint, project status, and whether the key was revoked. Do not print the full key while debugging.
Another error: record the HTTP status, official request identifier if present, and sanitized message; then use the Kimi API errors guide.

Once authentication is confirmed, use the API Quickstart for the first chat completion and the Kimi API models guide for workload selection.

Separate Development, Staging, and Production

One key for every system makes incidents harder to contain. Split environments so that a local experiment cannot consume the production budget and a leaked staging secret can be revoked without taking the live service offline.

Environment	Recommended boundary	Key owner	Typical control
Development	Dedicated project or tightly limited development scope	Individual developer or development service	Small budget, non-sensitive test data, frequent rotation
Staging	Separate project and deployment secret	Staging service account or responsible operator	Production-like tests without production data
Production	Production-only project and secret manager	Named service owner	Alerts, restricted access, documented rotation and rollback

For a team, prefer individual keys or service-specific credentials rather than sending one shared value through email or chat. Removal of a member, vendor, or application should have a matching key-revocation step.

WordPress and Browser Apps: Keep the Key Behind a Backend

A secret embedded in JavaScript, a mobile bundle, a public repository, a page source, or a WordPress shortcode output is not secret. The safe request path is:

Browser: sends the user’s request to your own authenticated WordPress REST endpoint.
WordPress backend: validates nonce or session, rate-limits the user, checks payload size, and retrieves the API key from a server-side secret.
Kimi API: receives the server-to-server request.
Backend: filters the response, records minimal operational metrics, and returns only the needed result to the browser.

Do not expose the key through wp_localize_script(), HTML data attributes, front-end environment variables, downloadable configuration files, or client-side fetch calls. Add per-user limits, global budget controls, timeout handling, and abuse protection before making a public tool available.

Rotate a Key Without Downtime

Create a replacement key in the same intended project and record its new rotation date.
Add the replacement to the secret manager without deleting the old value yet.
Deploy the new secret to one test or canary instance.
Run the authentication check and one normal application health check.
Roll out to all instances and confirm that requests use the replacement.
Revoke the old key in the official console.
Monitor for failures from forgotten jobs, old servers, developer machines, and scheduled tasks.

If the Key May Have Been Exposed

Treat suspected exposure as real. Do not wait for proof of misuse and do not merely remove the key from the latest Git commit; copies may remain in history, logs, caches, build artifacts, screenshots, and messages.

Revoke the affected key immediately.
Create and deploy a replacement through the rotation process.
Review usage and billing around the earliest possible exposure time.
Search repositories, history, CI logs, support tickets, analytics, and chat systems for the leaked value or recognizable prefix.
Remove the secret from history and artifacts using the appropriate repository and deployment procedures.
Record the root cause and add a preventive control such as secret scanning, log redaction, or a blocked client-side build variable.
Contact official platform support when unauthorized usage or billing is suspected.

Where to Go After the Key Is Safe

Next job	Use this page
Send the first authenticated chat request	Kimi API Quickstart
Choose a model by workload and acceptance test	Kimi API Models
Estimate token and request cost	Kimi API Pricing
Use an OpenAI-format client or framework	Kimi OpenAI-Compatible API
Diagnose a status code or error payload	Kimi API Errors

Frequently Asked Questions

Is a Kimi API key included in my personal Kimi membership?

Do not treat personal membership and Open Platform API billing as the same product. Create and fund the appropriate developer account for programmatic requests.

Can I put the Kimi API key in browser JavaScript?

No. A browser user can inspect the bundle, network activity, page source, and runtime values. Proxy requests through a controlled backend and keep the key in server-side secret storage.

Should a whole team share one API key?

Prefer individual or service-specific keys within managed projects. This improves attribution, rotation, offboarding, incident containment, and cost investigation.

How do I know whether the key works?

Call the official GET /v1/models endpoint with Bearer authentication. A successful model-list response verifies authentication. Then use the Quickstart for a full request.

How often should I rotate the key?

Use an organization-defined schedule and rotate immediately after suspected exposure, personnel changes, vendor offboarding, project transfer, or a security-policy trigger. The correct interval depends on your risk and deployment controls.

Why does my third-party Kimi key fail on the Moonshot endpoint?

Keys are tied to the issuing platform. A third-party or regional key must use that provider’s endpoint, model identifiers, billing, and documentation unless the provider explicitly states otherwise.

Official Sources and Verification

Last verified: August 31, 2026.