Create a sandbox API key from the dashboard, CLI, or MCP, store it on your server, and rotate it safely.
An API key gives your server access to one Commet organization. Start with a sandbox organization while building your integration.
New full-access keys start with ck_sandbox_ or ck_live_; new restricted keys start with rk_sandbox_ or rk_live_. Existing ck_ keys remain valid. The organization that created the key determines which data it can reach. Both environments use https://commet.co/api/v1.
Choose the path that fits where you are working. You only need one to get started.
Local development, and choose Expires In (Days). The dashboard accepts 1–365 days and defaults to 365.Install the Commet CLI, sign in through your browser, and link the project to your sandbox organization:
npm install -g commet
commet login
commet linkChoose the organization marked sandbox. Linking a new organization generates a key for CLI resource commands and saves it in .commet/config.json. The CLI adds .commet/ to .gitignore. Keep that directory private.
This configures the CLI; it does not set COMMET_API_KEY for your application. To create a separate application key after linking:
commet api-keys create --name "Local development" --expires-in-days 365Save the returned apiKey as described below. Resource commands use COMMET_API_KEY from the environment before the linked project's key, so check which credential is active before creating or deleting keys.
Connect your agent to the Commet MCP server at https://commet.co/mcp/v2. With OAuth, you can sign in through your browser and select a sandbox organization without an existing API key. The connection stays fixed to that organization.
Ask the agent to create an application key using api_create_api_key with these arguments:
{
"body": {
"name": "Local development",
"expiresInDays": 365
}
}The response contains the full secret only once. Have the agent store it directly in the intended local secret file or secret manager when your tools support that. Do not paste an existing secret into the conversation or ask the agent to repeat it in a message.
Already authenticating with a full-access API key? You can create replacements with POST /api/v1/api-keys. That request creates another key for the same organization. See Create API key for the request and response.
Leave permissions out to create a full-access key. Provide resource grants to create a restricted key. For example, a key with customer: ["read"] can read customers but cannot change them. Write access requires both "read" and "write". An empty object ({}) grants no resource access.
A restricted key with api_key: ["read", "write"] can create restricted keys with the same or fewer permissions. These keys expire no later than the key that creates them. Restricted keys cannot edit or delete API keys.
const key = await commet.apiKeys.create({
name: "Customer reader",
permissions: { customer: ["read"] },
})The full secret is returned once. Save it in your secret store before leaving the response.
For local development, save the key in a git-ignored environment file:
COMMET_API_KEY=ck_replace_with_your_keyLoad this variable into your server process using your framework's environment support. For production, use your deployment's secret store. Never expose the key in browser code, public environment variables, logs, screenshots, or source control.
Commet stores a hash of the key and cannot show the full secret again. If you lose it, create a replacement.
For Node.js, install the SDK:
npm install @commet/nodeInitialize it in server code after loading the environment:
import { Commet } from "@commet/node"
const apiKey = process.env.COMMET_API_KEY
if (!apiKey) {
throw new Error("COMMET_API_KEY is required")
}
export const commet = new Commet({ apiKey })For other languages, follow the Python, Go, Java, or PHP integration guide. Direct REST requests authenticate with the x-api-key header.
Use a separate key for each application or deployment that needs independent rotation. To replace a key before it expires:
For production, create a key in your live organization and store it separately from sandbox credentials. Do not copy sandbox customer, plan, or subscription IDs into live configuration. Before switching, verify checkout, webhooks, and a renewal in sandbox with the Test Clock.
Next, follow the quickstart to complete your first subscription payment in sandbox.
How is this guide?