What Is an API Key
Understand the purpose, format, security boundaries of an API Key, and how it differs from text billing units
An API Key is the credential you use when calling MoleAPI. In the MoleAPI console, it is also commonly referred to as a Token.
When you use an SDK, a client application, or your own HTTP requests to connect to MoleAPI, the system uses this Key to determine:
- Who you are
- Whether you have permission to call the API
- Which models you can access
- Which account and which Key the usage should be attributed to
The simplest way to understand it
You can think of an API Key as:
- Externally: an "API password"
- Internally: an "access credential + billing attribution label + permission switch"
In other words, it is not just a string that determines whether you can call the API. It also affects:
- Call log attribution
- Available model scope
- Group policies
- Security restrictions
- Quota control
Typical format
A MoleAPI API Key usually looks like this:
sk-********************************In many third-party applications, it may appear in input fields labeled:
API KeySecret KeyTokenBearer Token(a compatible label used by some clients or interfaces)
API Key and text billing units are not the same thing
This is the most common point of confusion for beginners.
Two concepts that are easy to confuse
- API Key / Token: An identity credential used to call the API.
- Text billing unit (Token): The billing unit used when a model processes text, for cost calculation.
That means:
- What you create is an API Key
- What you consume is text billing usage / request cost
These two concepts are completely different.
Why create multiple API Keys for one account
In theory, you can use just one Key, but in practice this is not recommended.
A better approach is to separate them by use case, for example:
dev-local: local debuggingchatbox-test: desktop client testingweb-prod: production website backendops-batch: scheduled tasks or batch processing
Benefits of doing this include:
- Clearer logs: You can quickly see which system is making calls
- Better access control: Different Keys can have different models and limits
- Lower risk: If one Key is leaked, it does not affect all services
- Better cost allocation: It is easier to determine who spent what
Where API Keys are typically stored
In practice, common places to store an API Key include:
- The settings page of a local client application
- Server environment variables
- Backend configuration files (not publicly accessible)
- Secret management systems
If you are a developer, the most common pattern usually looks like this:
export OPENAI_API_KEY="sk-..."Or it is sent in the program as a Bearer authentication header.
When you should recreate or replace an API Key
In the following situations, it is recommended to create a new Key instead of continuing to reuse an old one:
- You are preparing to separate the test environment from the production environment
- You need to assign independent API permissions to different projects
- You need to restrict the scope of newly available models
- You suspect the old Key has been leaked
- You want clearer log auditing and cost allocation
Security recommendations
If an API Key is leaked, it effectively means your API access has been leaked
Do not expose your API Key in public environments. Otherwise, someone else may use it directly against your quota.
At a minimum, avoid the following practices:
- Do not put it in frontend source code
- Do not commit it to a Git repository
- Do not share it in chat groups, ticket screenshots, or public documentation
- Do not leave production Keys scattered across multiple personal devices for long periods
Recommended practices:
- Use different Keys for testing and production
- Configure model restrictions or an IP allowlist for critical Keys
- Rotate long-lived Keys regularly
- Disable or delete old Keys immediately when abnormal usage is detected
What to read next
If you already understand the role of an API Key, the next recommended reads are:
How is this guide?
Last updated on