Kimi K3 API Key Setup: Endpoint, Model ID, and Python

A Kimi K3 API key is useful only when the key, endpoint, model ID, and request format all agree. Kimi K3 is a new reasoning model with a large context window, but a valid credential can still produce a 400 or 404 response if an application sends the request to the wrong provider URL, uses kimi/kimi-k3 instead of kimi-k3, or copies a parameter from a different API surface.

This guide shows the shortest reliable path to a first Kimi K3 request through OurToken. You will create or locate an API key, configure the OpenAI-compatible Chat Completions endpoint, send a cURL request, repeat it from Python, and then add production safeguards. The examples use the current OurToken route:

https://api.ourtoken.ai/v1/chat/completions

The official Kimi platform also exposes Kimi K3 through an OpenAI-compatible interface, but its provider base URL is different. Keeping the two routes separate is the central configuration rule in this article.

This article uses the current OurToken Kimi K3 model reference and the official Kimi K3 quickstart as documentation sources. Provider routes, prices, supported fields, and limits can change, so recheck the live model page before deploying.

Verification status: The examples are documentation-verified against the public provider pages, but were not executed with a live API key in this draft. Run the minimal cURL request and inspect its response before using optional features or production traffic.

How to Get a Kimi K3 API Key

An API key is a server credential for programmatic access. It is not the same as a Kimi web login, a Moonshot dashboard session, or a model ID. The key authenticates the request; the model ID tells the provider which model route to run.

For the OurToken route, open the Kimi K3 API page and follow its API access link, or go directly to the protected OurToken API Keys page. You may be redirected to login before key management becomes available. After creating a key, copy it once into a server-side secret manager or an environment variable. Do not put it in browser JavaScript, a public repository, a blog post, or a screenshot.

Keep the five configuration values separate

Treat these values as independent settings rather than one hard-coded URL:

The model page is the compatibility boundary for the OurToken route. It currently documents the kimi-k3 model ID, the /chat/completions operation, and max_tokens in the request body. That does not mean every parameter from the official Kimi API should be copied without checking the OurToken route.

Set the credential in your local shell before testing.

On macOS or Linux:

export OURTOKEN_API_KEY="paste-your-key-locally"

On Windows PowerShell:

$env:OURTOKEN_API_KEY = "paste-your-key-locally"

The variable name is local to your application. The request still sends the credential through the standard HTTP header:

Authorization: Bearer YOUR_API_KEY

If a command prints the key while debugging, treat it as exposed and rotate it. The safest first test records only the HTTP status, response ID, model ID, and usage fields needed for cost tracking.

What the key does not prove

Authentication is only the first boundary. A successful key check does not prove that:

• the selected model ID exists on the provider route;
• the endpoint accepts the parameter names in your request;
• the account has enough balance or quota;
• the model supports the feature you want to add;
• your application handles rate limits and incomplete responses.

That is why the initial request should use one model, one short message, and a small output limit. Add vision, tools, long context, and reasoning controls only after the basic request works.

Kimi K3 API Endpoint and Model ID

The Kimi K3 API endpoint has a base URL and an operation path. For the current OurToken integration, use:

Base URL:   https://api.ourtoken.ai/v1
Operation:  /chat/completions
Full URL:   https://api.ourtoken.ai/v1/chat/completions
Model ID:   kimi-k3

The OurToken Kimi K3 model page currently lists a 1,048,576-token context window, the kimi-k3 model ID, and the full Chat Completions URL. The current page also shows the route's input and output pricing, so use it as the source of truth for a production budget.

Do not mix the official and OurToken routes

Both providers use an OpenAI-compatible request shape, but the base URLs are not interchangeable:

The official Kimi examples use the official provider key and base URL. The examples below use an OurToken key and OurToken base URL. Do not combine an official MOONSHOT_API_KEY with api.ourtoken.ai, or an OurToken key with api.moonshot.ai.

The URL path used by the website is also not the model ID:

• Website catalog path: /models/kimi/kimi-k3
• API model value: kimi-k3

Do not send kimi/kimi-k3, moonshotai/kimi-k3, or a display label such as Kimi K3 unless the provider documentation for the endpoint explicitly accepts that value.

Request architecture

Make each boundary visible when debugging:

Your application
      |
      | Authorization: Bearer OURTOKEN_API_KEY
      v
https://api.ourtoken.ai/v1/chat/completions
      |
      | model = kimi-k3
      v
Kimi K3 route
      |
      v
Chat completion + usage data

For an OpenAI-compatible SDK, set the base URL to https://api.ourtoken.ai/v1. Do not set it to the full /chat/completions URL unless that SDK explicitly documents a full-operation base URL. Most SDKs append the operation path themselves, and using the full URL as base_url can create a duplicated path.

One parameter difference deserves special attention. The current OurToken Chat Completions reference documents max_tokens. The official Kimi K3 documentation uses max_completion_tokens as its output-limit parameter, but a parameter documented by the official provider is not automatically enabled on a compatible provider route. Start with max_tokens on OurToken and add max_completion_tokens only after the route accepts it.

Kimi K3 cURL Example

A direct cURL request is the fastest way to test a new Kimi K3 API key because it removes SDK version differences from the first diagnostic. It exposes the exact URL, headers, model value, message shape, and output limit.

On macOS or Linux:

curl -sS https://api.ourtoken.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $OURTOKEN_API_KEY" \
  -d '{
    "model": "kimi-k3",
    "messages": [
      {
        "role": "user",
        "content": "Give me a three-item checklist for reviewing a database migration."
      }
    ],
    "max_tokens": 256
  }'

On Windows PowerShell, use curl.exe rather than the PowerShell web-request alias:

curl.exe "https://api.ourtoken.ai/v1/chat/completions" -H "Content-Type: application/json" -H "Authorization: Bearer $env:OURTOKEN_API_KEY" -d '{"model":"kimi-k3","messages":[{"role":"user","content":"Give me a three-item checklist for reviewing a database migration."}],"max_tokens":256}'

The request contains the five important pieces: an OurToken API key, the OurToken Chat Completions URL, the exact kimi-k3 model ID, a messages array, and an output cap. Keep the first prompt short so a failure is attributable to authentication or routing rather than context size.

Inspect the response

A completed Chat Completions response normally contains a completion ID, the requested model, a choices array, and usage data. The current OurToken model reference documents usage fields in the Chat Completions shape:

{
  "id": "chatcmpl-example",
  "object": "chat.completion",
  "model": "kimi-k3",
  "choices": [
    {
      "message": {
        "role": "assistant",
        "content": "..."
      }
    }
  ],
  "usage": {
    "prompt_tokens": 123,
    "completion_tokens": 87,
    "total_tokens": 210
  }
}

For the first test, check:

1. The server returned HTTP 200.
2. The response model is kimi-k3.
3. choices[0].message.content contains an answer.
4. usage.prompt_tokens and usage.completion_tokens are present when the provider returns usage.
5. No API key appears in the terminal output or application logs.

If the response returns an error object, save the status code and error class, not the full credential. A 401 points to authentication. A 404 usually points to the base URL, operation path, or model ID. A 400 usually means the body shape or a parameter does not match the route.

Kimi K3 Python API Usage

The OpenAI Python SDK can call an OpenAI-compatible Chat Completions route. Install the SDK in the environment that runs the application:

python -m pip install --upgrade openai

Then use the OurToken base URL and the exact model ID:

import os

from openai import OpenAI


client = OpenAI(
    api_key=os.environ["OURTOKEN_API_KEY"],
    base_url="https://api.ourtoken.ai/v1",
)

completion = client.chat.completions.create(
    model="kimi-k3",
    messages=[
        {
            "role": "user",
            "content": "Give me a three-item checklist for reviewing a database migration.",
        }
    ],
    max_tokens=256,
)

print(completion.choices[0].message.content)
print(completion.id)

if completion.usage:
    print("prompt_tokens:", completion.usage.prompt_tokens)
    print("completion_tokens:", completion.usage.completion_tokens)
    print("total_tokens:", completion.usage.total_tokens)

This example intentionally uses client.chat.completions.create, not client.responses.create. Kimi K3's current OurToken page documents the Chat Completions route, and its request field is max_tokens. The official Kimi quickstart uses the same SDK method with a different provider base URL.

For usage accounting, keep the provider's raw field names when you record events. Renaming prompt_tokens to input_tokens inside your own internal schema is fine, but document that it is an application-level normalization. Do not silently mix usage objects from Chat Completions and Responses API responses because their field names and nested details can differ.

Continue a multi-turn conversation

Kimi K3 is designed for long-horizon work, but multi-turn code needs to preserve the complete assistant message. Do not keep only the visible content string when a response can contain reasoning or tool-call fields. Start with a normal request, append the complete assistant message, and then send the next user message:

import os

from openai import OpenAI


client = OpenAI(
    api_key=os.environ["OURTOKEN_API_KEY"],
    base_url="https://api.ourtoken.ai/v1",
)

messages = [
    {
        "role": "user",
        "content": "List the three highest-risk areas in this deployment plan.",
    }
]

first = client.chat.completions.create(
    model="kimi-k3",
    messages=messages,
    max_tokens=512,
)

assistant_message = first.choices[0].message
messages.append(assistant_message)
messages.append(
    {
        "role": "user",
        "content": "Turn those risks into a release-blocking checklist.",
    }
)

second = client.chat.completions.create(
    model="kimi-k3",
    messages=messages,
    max_tokens=512,
)

print(second.choices[0].message.content)

This pattern keeps the assistant message that the model returned. If you add tools, preserve the tool-call fields and submit tool results in the format required by the provider. The OpenAI-compatible tool-calling guide covers the cross-provider concerns that become important after the first text request.

Reasoning controls are optional

The official Kimi K3 documentation says that K3 always reasons and currently supports only reasoning_effort="max". The current OurToken model page does not list every official K3-specific parameter in its generic request table, so do not add this field to the first smoke test. If the live OurToken route confirms support, test it as a separate request:

reasoning_completion = client.chat.completions.create(
    model="kimi-k3",
    messages=[
        {
            "role": "user",
            "content": "Find the most likely failure mode in this deployment plan.",
        }
    ],
    reasoning_effort="max",
    max_tokens=1024,
)

If the route returns an unsupported-parameter error, remove reasoning_effort and rely on the model's documented default behavior. Do not copy Kimi K2.x's thinking parameter into a Kimi K3 request.

From First Request to Production

A successful smoke test proves that one request works. Production integration needs a small layer around the request so that credentials, model selection, cost, context size, and failures remain observable.

Kimi K3 pricing and a simple cost estimate

The current OurToken Kimi K3 API page lists Kimi K3 at 60% of the displayed official reference price. The official Kimi K3 pricing page explains the provider's current billing categories. The OurToken page currently shows these per-million-token rates:

Prices can change, so treat this as a dated example rather than a permanent quote. For a request with 20,000 input tokens and 2,000 output tokens:

Official reference:
20,000 / 1,000,000 * $3.00  = $0.060
 2,000 / 1,000,000 * $15.00 = $0.030
Total                         = $0.090

OurToken listing:
20,000 / 1,000,000 * $1.80 = $0.036
 2,000 / 1,000,000 * $9.00 = $0.018
Total                       = $0.054

The calculation excludes retries, paid tools, and any non-token charges. It also does not assume that every application achieves the same cache-hit rate. Kimi's official documentation describes automatic context caching for regular requests: keep stable long prefixes unchanged so later requests can attempt a cache hit. The prompt caching guide explains the engineering tradeoffs for compatible API routes.

Long context needs a budget, not just a large limit

Kimi K3 is documented with a 1M-token context window, but a large context does not make every prompt economical or reliable. A production application should measure:

• prompt tokens before and after retrieval;
• output tokens and reasoning-related output where exposed;
• cache-hit tokens for repeated prefixes;
• request latency and retry count;
• cost per accepted task rather than cost per request only.

Use a per-feature budget. A document analysis workflow may justify a large context, while a classifier or router should usually cap input and output much lower. Do not set the maximum output to the largest allowed value by default; a large cap can increase cost and make incomplete responses harder to diagnose.

Optional vision, tools, and structured output

The official Kimi K3 documentation describes vision input, tool calls, JSON mode, structured output, automatic caching, and tool-choice controls. The OurToken model page also exposes generic fields such as tools, tool_choice, and response_format. Treat these as capability checks rather than assumptions:

1. Run the plain-text request first.
2. Add one optional field.
3. Check the status, output item, and usage.
4. Keep a rollback version of the minimal request.

For vision, follow the provider's input format rather than sending a public image URL by assumption. For tools, preserve the complete assistant message and tool-call identifiers. For structured output, test the actual JSON schema and validate the returned content before passing it to application code.

Configuration and retry policy

Keep the provider settings in one server-side configuration object:

import os


SUPPORTED_MODELS = {"kimi-k3"}
MODEL_ID = os.getenv("KIMI_K3_MODEL_ID", "kimi-k3")
BASE_URL = os.getenv("KIMI_K3_BASE_URL", "https://api.ourtoken.ai/v1")
API_KEY = os.environ["OURTOKEN_API_KEY"]

Validate the model ID at startup. A user-facing model selector should resolve to the server-side allowlist instead of accepting arbitrary model strings from an untrusted browser.

Not every failure should be retried:

Be cautious when a request includes tools or external side effects. A retry after a timeout may run the model again even when the client did not receive the first response. Record a request ID, model ID, status, latency, retry count, and estimated cost without logging the API key or sensitive prompt content.

A release checklist

Before connecting Kimi K3 to production traffic:

1. Confirm OURTOKEN_API_KEY is available only to the server process.
2. Run the minimal cURL request and save a redacted response.
3. Run the same prompt through the Python SDK.
4. Confirm model is kimi-k3 and the route ends in /chat/completions.
5. Record prompt_tokens, completion_tokens, and total_tokens.
6. Test the application's real context size with a fixed output cap.
7. Add optional reasoning, tools, vision, or structured output one at a time.
8. Set retry, timeout, and budget limits before increasing concurrency.

Conclusion

The reliable Kimi K3 API setup is small: create an OurToken key, set https://api.ourtoken.ai/v1 as the SDK base URL, call /chat/completions, and send the exact kimi-k3 model ID. Start with a short cURL smoke test, repeat it in Python, and only then add long context, automatic caching, reasoning controls, vision, or tools.

When you are ready to run the integration with a real credential, open the Kimi K3 API page to confirm the current route and pricing, then create a key through the OurToken API Keys page. Keep the key server-side and measure usage before moving from a test prompt to production traffic.

Frequently Asked Questions

How do I get a Kimi K3 API key?

Create a key with the provider that will receive the request. For the OurToken route, use the OurToken API Keys page, store the credential in a server-side environment variable, and send it as a Bearer token. A Kimi web login is not a substitute for an API key.

What is the Kimi K3 API endpoint?

The current OurToken full endpoint is https://api.ourtoken.ai/v1/chat/completions. When using an OpenAI-compatible SDK, set base_url to https://api.ourtoken.ai/v1 and call client.chat.completions.create.

What is the Kimi K3 model ID?

The OurToken model ID is kimi-k3. Use that exact value in the request body. Do not copy the catalog path kimi/kimi-k3 or a model label into the API request.

Can I use Kimi K3 from Python?

Yes. Install the OpenAI Python SDK, set the OurToken base URL, pass the API key from an environment variable, and call client.chat.completions.create with model="kimi-k3". Start with max_tokens, which is the parameter documented by the current OurToken Chat Completions route.

Should I use Responses API for Kimi K3?

Use the Chat Completions route documented on the current OurToken Kimi K3 page. Do not switch to /responses just because another OpenAI-compatible model uses Responses API. Endpoint compatibility is model- and provider-specific.

Does Kimi K3 support reasoning?

Kimi K3 always reasons according to the official documentation, and the official route currently exposes reasoning_effort="max". The OurToken page may not expose every official parameter in its generic request table, so test the field separately and remove it if the route returns an unsupported parameter error.

Does Kimi K3 support a 1M-token context?

The official Kimi documentation and the current OurToken model page describe a 1,048,576-token context window. That is a limit, not a recommendation. Measure prompt size, cache behavior, latency, and cost before sending very large requests.