Skip to main content
API keys are the simplest way to authenticate with Jinko. They prefix with jnk_ and work everywhere, the SDK, the CLI, MCP clients, and direct REST calls. Use them for: agents, scripts, CI/CD, server-side apps, MCP clients without OAuth support. Don’t use them for: end-user-facing OAuth flows in MCP clients that support DCR (Claude Desktop, ChatGPT, Cursor, Codex, Openclaw).

​
Get a key

There are two ways to get a key. If an AI coding agent is doing the work, it can mint the key itself — it does not need a human to visit the dashboard.
Works with any MCP-capable coding agent — Claude Code, Codex, Cursor, Openclaw, Lovable, Replit, opencode, and others. Add the Jinko platform MCP server and call its get_api_key tool:
Add it the way your agent adds any remote MCP server: a CLI command (claude mcp add --transport http jinko-platform <url>), an entry in the client’s MCP config, or — on hosted builders like Lovable and Replit — by pasting the URL into their integrations UI.The user signs in once through their browser (OAuth). get_api_key then bootstraps their organization and tenant if they don’t exist yet and returns a jnk_ key, together with connection instructions for the REST API, SDK, CLI, and booking MCP.
The key you get this way is an ordinary server-to-server key. Wire it into the backend you’re building — it is not limited to chat or to the MCP session that minted it. There is no need to send the user to the dashboard or to ask them to paste a key.
The same MCP also serves these docs (search_docs, get_doc, get_openapi), so an agent can go from “no account” to a working integration without leaving the session.

​
Use a key

Or via env: export JINKO_API_KEY=jnk_... and call createJinkoClient() with no args.

​
Sandbox keys

Jinko runs two isolated environments: production and sandbox (test the full flow without touching prod data). They use separate keys: a jnk_ key is scoped to the environment it was created in and won’t authenticate against the other. Generate a sandbox key from the dashboard, then point your client at the matching base URL: The CLI and SDK have built-in environment switching (they store the two keys separately); for REST/MCP just use the sandbox URL above with your sandbox key.
Sandbox calls are not billed and are not refused for lack of credit. The credit model described in Limits & credits — dollar metering against your organization’s balance, and the 402 when it runs out — applies to production only. A sandbox key is not metered against a balance, so you can exercise a full booking flow there without spending your monthly grant.This is about credit, not about limits in general: sandbox is a shared test environment, so build against it as you would production rather than treating it as unmetered capacity.

​
Rotation

If a key leaks (committed to git, posted in chat, etc.):
  1. Create a new key in the dashboard.
  2. Update your scripts / env / config to use the new key.
  3. Delete the old key in the dashboard. Anything still using it stops working immediately.
Always rotate; never edit a key in place. There’s no rate-limited grace period.

​
Credit

Keys have no request quota. Usage is metered in US dollars against the organization’s credit balance, and every key under the organization draws on that same balance — so splitting work across several keys does not give you more to spend. The Free plan includes $5.00 of usage per month, which does not roll over into the next cycle. When the balance runs out, calls return 402 PAYMENT_REQUIRED and the key stays active — top up and it resumes. See Limits & credits for the full picture, including the separate per-second rate limit.

​
Common failures

For 4xx debugging, also check the response body, Jinko returns a structured error object with a code and message. See Errors & troubleshooting.