Skip to main content

​
Overview

JieKou AI uses Bearer authentication for API access. Send your API key in the Authorization request header, for example: “Authorization: Bearer {API Key}”. Every API key begins with the sk_ prefix followed by a random string. You set a key’s expiration when you create it; see Key expiration. Go to Key Management to view and manage your API keys.
You create and delete API keys in the console only. The OpenAPI has no endpoints for creating or deleting keys, and it does not support setting or changing a key’s expiration. The OpenAPI does support reading and writing a single key’s network access policy; see Get API Key IP Access Policy.

​
Create an API key

  1. Go to Key Management and click + Create.
  2. Enter a key name, choose an expiration, then click Confirm.
  3. Save the key.
    The full key is shown only once, when it is created. Store it in a secure location. If you lose it, you cannot recover it; create a new key instead.

​
Manage API keys

For existing API keys, you can:
  • Rename: click the key’s edit button, enter a new name, then click Confirm.
  • Delete: click the key’s delete button and confirm.
A deleted key stops working immediately and cannot be restored. Every call that uses it returns an authentication failure (HTTP 401). Before deleting a key, make sure no production workload still uses it.

​
Key expiration

When you create an API key, choose one of four expiration options: Permanent, 90 days, 30 days, 24 hours.
You set the expiration when you create the key. It cannot be changed afterward: you cannot renew a key or expire it immediately. Permanent keys remain valid indefinitely, so a leaked key remains usable for longer. Use permanent keys only when appropriate. Expiration cannot be set or changed through the OpenAPI; you set it in the console when you create the key.
The key list and key settings show one of three expiration states: An expired key is rejected when used, but its configuration remains visible and the delete action is still available. Expiration is different from disabling a key. To restore access, create a new key. To disable a key before it expires, delete it in the console; the deletion takes effect immediately.

​
Access controls

You can restrict which models an individual API key can call and which source IPs can use it:

Model Access

Limit the models a key can call, and learn what happens when a model goes offline or a call is rejected.

Network Access

Limit the allowed IPv4 addresses or CIDR ranges to reduce the impact of a leaked key.

​
Usage and budgets

JieKou AI budgets are set per team member. All API keys created by the same member share that member’s budget pool. When a member’s budget runs out, calls from all keys under that member are paused. See Budget Management for configuration and budget types.

​
Store your key as an environment variable

Hardcoding a key in source code can expose it, for example when you commit the file. Reading it from an environment variable such as JIEKOU_API_KEY keeps it out of your source code, for example os.environ["JIEKOU_API_KEY"].

​
Temporary vs. permanent

  • Temporary: lasts only for the current terminal session and is gone when you close it. Suitable for a quick test.
  • Permanent: written to your shell profile or system environment, so it persists in new terminals and after a restart. Suitable for long-term use.
The examples below use the variable name JIEKOU_API_KEY.
Temporary (current terminal session only):
Permanent (append to ~/.bashrc for bash; use ~/.zshrc for zsh):
Verify:

​
The variable is set but the code still can’t find it

If your code still cannot read the key, check the following:
  • You only set it temporarily: a variable set with export or $env: exists only in the current terminal session. Use a permanent variable (~/.bashrc / ~/.zshrc / setx) for long-term use.
  • You changed the profile but didn’t reload it: after editing ~/.bashrc or ~/.zshrc, run source on the file or open a new terminal. IDE terminals usually need an IDE restart to pick up new variables.
  • A process manager doesn’t inherit your shell environment: services run by systemd, supervisor, PM2, and similar tools do not inherit your login shell’s variables. Declare the variable in each service’s own configuration.
  • sudo doesn’t pass your environment through: sudo uses a clean environment by default. Use sudo -E to preserve it, or set the variable in the root environment.

​
Security best practices and leak response

An API key is equivalent to an account credential: anyone who holds it can call the API as you and incur charges. Follow these practices:
  • Store keys in environment variables: keep keys in environment variables or a secrets manager, not in source code.
  • Don’t commit keys: never commit keys in code or config files to Git. Remove keys before sharing code or screenshots.
  • Don’t ship keys to the frontend: don’t use keys directly in browser or mobile app code, where they can be extracted. Route calls through your own backend.
  • One key per environment: use separate keys for production, testing, and CI, and for different purposes, so you can disable and troubleshoot them independently.
  • Narrow permissions with model access and network access: use Model Access to limit which models a key can call, and Network Access to limit its allowed source IPs.
  • Rotate regularly: create a new key, switch your workloads to it, verify in production, then delete the old key for a zero-downtime rotation.

​
If a key leaks

If you suspect a key has leaked (for example, it was committed to a public repository or appeared in logs or screenshots):
  1. Go to Key Management immediately and delete the key.
  2. Create a new key and update every workload that used the old one. Configure Network Access on the new key to allow only your workload’s egress IPs.
  3. Review Audit Log for unusual operations, and check Budget Management for unexpected spend.
  4. To tighten team members’ permissions over keys, see Team Management.
Last modified on October 12, 2026