Create a Kimi API credential inside the project that should own its usage. Match the key to the documented endpoint, configure spending controls and verify a small request before expanding access.

Before you start

Identify the organization, project and person responsible for the application. For a shared service, document which deployed process will read the secret and how that process can be stopped. This keeps key setup connected to operational ownership instead of leaving a powerful credential in an unexplained local file.

The Kimi quickstart directs developers to the API Keys console and recommends storing the secret in an environment variable. Official documentation.

Open the console through that official route. Confirm the active workspace before creating anything. A browser can have multiple signed-in accounts, while a terminal can retain an older environment value. Treat those as separate states that must agree when you verify the request.

Step-by-step: create the key

  1. Open the Kimi API Platform from the official quickstart and confirm the intended account.
  2. Select the organization and application project before opening its API-key controls.
  3. Create a credential for the responsible project member and give its purpose a recognizable label where supported.
  4. Copy the secret directly into protected environment configuration; keep a record of its owner and purpose without the secret value.

The screenshot checklist for this page records the actual console steps separately. It must show current navigation and controls with secret values and account identifiers removed. A drawn console or a borrowed screenshot would not establish the state of your account.

After saving the secret, close any unneeded reveal view. Do not paste it into an issue, copied command transcript or browser-side application bundle. The code below reads the environment rather than embedding the value, so it can be shared after inspecting the surrounding configuration.

Set a spending limit / budget alerts

Project settings support daily and monthly consumption budgets that deny later requests when enforced; billing delay can affect when enforcement begins. Official documentation.

Choose the boundary for the experiment and record the application behavior at that boundary. Treat the provider control as one part of the operating plan. A loop can create work rapidly before accounting catches up, so the application also needs a bounded number of attempts and a way to stop its queue.

Inspect the account’s available balance-notification controls and verify who receives them. An alert is useful only if its recipient can act. Keep the secret-rotation owner and the billing owner in the same operating note when they are different people.

Verify the key: first call with cURL and Python

curl https://api.moonshot.ai/v1/chat/completions --max-time 60 -H "Authorization: Bearer $MOONSHOT_API_KEY" -H "Content-Type: application/json" -d '{"model":"kimi-k3","messages":[{"role":"user","content":"Hello"}],"reasoning_effort":"low","max_tokens":1024}'
import os
import sys
from openai import OpenAI, APIStatusError

model = os.environ.get("MOONSHOT_MODEL", "kimi-k3")
if "--bad-model" in sys.argv:
    model = "ai-api-hub-invalid-model"
client = OpenAI(
    api_key=os.environ["MOONSHOT_API_KEY"],
    base_url="https://api.moonshot.ai/v1",
    timeout=60.0,
    max_retries=0,
)
try:
    result = client.chat.completions.create(
        model=model,
        messages=[{"role":"user","content":"Explain why a code patch needs a test in one sentence."}],
        reasoning_effort="low",
        max_tokens=1024,
    )
    print(result.choices[0].message.content)
    print("finish_reason:", result.choices[0].finish_reason)
    print(result.usage.model_dump_json() if result.usage else "Usage unavailable")
except APIStatusError as exc:
    print(f"HTTP {exc.status_code}")
    print(exc.response.text)
    raise SystemExit(1)
finally:
    client.close()

Run the example from the environment that will own the request. If the call fails before reaching the provider, distinguish a missing environment value or missing package from an API rejection. If a response arrives, inspect its completion state and usage instead of checking only that some text printed.

The following object is schematic, not a captured account response. It illustrates where an ordinary answer appears; your response includes its own identifiers, usage and completion details.

{"choices":[{"message":{"role":"assistant","content":"Example answer"},"finish_reason":"stop"}],"usage":{"prompt_tokens":12,"completion_tokens":18,"total_tokens":30}}

Where to put the key

Use MOONSHOT_API_KEY in the server process or secret store. The HTTP request sends it with the Authorization: Bearer header documented in the quickstart.

Check the launch path used by scheduled workers. An environment value available in an interactive terminal may be absent from a service or task runner. Verify that path with a safe test after changing secret configuration, and avoid printing the environment wholesale while troubleshooting.

Common rejections

Kimi keys are isolated by their issuing platform; a key and endpoint mismatch can produce an authentication failure. Official documentation.

Check the endpoint and active secret together before issuing replacements. For a permission rejection, inspect the project and organization configuration, including the network egress used by the deployed process. A passing request from a laptop does not establish that a server uses the same path.

Use the Kimi error guide to distinguish a malformed credential, a permission boundary, a depleted account and a traffic condition. Preserve the actual error type with the failing model identifier.

Rotate and revoke

Create a replacement under the intended ownership, deploy it to every consuming process and run the small verification request from those paths. Only then retire the old credential. Keep a list of background jobs so an infrequent worker does not fail later because it was omitted from the rotation.

Kimi recommends member-specific project keys; removing a member also invalidates that member’s keys. Official documentation.

Include this dependency in staff or service-account changes. Removing access is an appropriate control, but first identify which legitimate workloads depend on it and move their ownership deliberately. If a secret was exposed, revoke it promptly and inspect subsequent usage rather than relying on a filename change.

Use the AI API cost calculator to turn the model and workload you are considering into an estimate.

Last verified · Source ↗

Frequently asked questions

Which environment variable does the example read?
MOONSHOT_API_KEY.
Why can a valid-looking key fail at this endpoint?
Check that the key was issued by the platform corresponding to the selected endpoint, then inspect the actual authentication response.
Does a budget reject requests immediately in every circumstance?
The provider documents an enforcement delay associated with billing; keep application stop conditions as well.
Where should a production credential be stored?
In protected server-side configuration or a secret-management service used by the deployed process.
What happens to member-created keys when membership is removed?
The organization documentation states that the removed member’s keys are invalidated.
Can I share the response while requesting help?
Share only a minimal redacted response and reproduction, with secrets and unrelated account information removed.

Sources

Last verified · Source ↗