Skip to main content
An API key authenticates your requests to Novita AI. This page covers how keys work, how to create and store one, and how to keep it working across your environments. Use this page to:
  • Authenticate requests to Novita AI with a Bearer API key.
  • Create an API key from the console and store it safely.
  • Configure your key as an environment variable on Linux, macOS, and Windows.
  • Understand how long a key stays valid and what the OpenAPI does and does not cover.

Authentication

Novita AI authenticates API access using Bearer authentication. Send your API key in the Authorization request header:
An example request:

Create an API key

1

Open Key Management

Go to Key Management in the console.
2

Create a new key

Select Create API Key, then give the key a name that reflects its purpose, such as production or local-testing.
3

Copy and store the key

The full key is shown only once, at creation. Copy it immediately and store it somewhere safe, such as a secrets manager or an environment variable. If you lose it, you cannot recover it — create a new key instead.
Optionally, you can limit which models a key is allowed to call. See Model Access for API Keys.

Key format and validity

  • Every key begins with the sk_ prefix.
  • A key is shown in full only once, at creation. Afterward, the console displays a masked form.
  • A key stays valid indefinitely once created. It keeps working until you delete it in the console.
  • Each account can create up to 10 API keys.

What the OpenAPI covers

You create and delete API keys in the console only. The Novita OpenAPI does not include endpoints to create or delete keys. The key-related OpenAPI endpoints cover listing keys and managing a key’s model access policy:

Store your key as an environment variable

Hardcoding a key in source code risks leaking it, for example when you commit the file. Reading the key from an environment variable such as NOVITA_API_KEY keeps it out of your code.

Temporary vs. permanent

A key set with export (Linux/macOS) or set (Windows) lasts only for the current terminal session and is gone when you close it. That is fine for a quick test. To keep the key across sessions, set it permanently as shown below, then open a new terminal so the change takes effect.
Read the key back in your code from the environment:

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

A key set with export or $env: lives only in the terminal session where you ran it. A new terminal, or a new tab, does not inherit it. Set the key permanently (>> ~/.zshrc, setx), or re-run the export/$env: line in the session you are using.
A permanent change (shell profile, setx) applies to terminals started after the change. Open a new terminal, and restart your IDE or editor so it picks up the new environment. On Windows, setx does not affect terminals that are already open.
Processes launched by systemd, supervisor, Docker, or a CI runner do not read your interactive shell profile. Set the variable in the service’s own configuration (for example, a systemd unit’s Environment=, a docker run -e flag, or the CI project’s secrets), not in ~/.bashrc.
sudo does not pass your environment through by default, so the variable you exported as your user is not visible to the elevated process. Use sudo -E to preserve the environment, or set the variable within the elevated context.
Last modified on August 4, 2026